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ABSTRACT 


This thesis successfully demonstrates the ability to apply realistic visualization 
to a training application with a commercially available software program. It is 
increasingly important with the trend of decreasing military spending to maintain 
force readiness through quality training. Utilization of realistic visualization in 
simulations of realtime scenarios is essential to achieving this quality training. This 
thesis utilizes the Improved Target Acquisition Algorithm for Janus (A) in the 
visualization of sensor to moving target lines of sight. This visualization takes 
place in an obstruction constrained terrain using a representation of the higher 
resolution one meter style Pegasus database numbers. 
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I. BACKGROUND 


A. INTRODUCTION 

Operating at sea, out in the field, or in the air is how military personnel receive 
a majority of their training in order to become proficient at their jobs. By practicing with 
actual equipment and situations, personnel are able to absorb critical information in order 
to make intelligent informed decisions. With decreasing military budgets, operational 
training has had to be severely curtailed due to lack of funds. To maintain operational 
readiness, today’s military has to rely heavily on "schoolhouse" training instead of 
"operational" training. There has to be a way to train in a schoolhouse environment and 
yet achieve an operational environment as close to actually being out there in order to 
maintain proficiency in critical skills. 

This is where simulation becomes an integral part of training. In order for 
simulation to achieve its goal of realistic training, it must be sensed as real. Visualization 
gives simulation this sense. In a simulation, it is critical to be able to see what looks like 
a ship, tank, or plane moving across a real terrain in real time, instead of an object 
moving across a two dimensional contour plane. 

Having the capability to train with realistic visualization and do it cost efficiently 
is a top priority. Cost effectiveness is based in part on the ability to not have to reinvent 
the wheel for every different type of simulation. If software packages available 
commercially can be adapted into existing simulation programs, with minimal 
programming, cost effectiveness would be achieved. This is the major thrust of this 
thesis. 

B. JANUS 

1. Background 

Janus Army or Janus (A) is a computer based, interactive, two-sided, closed, 
stochastic, ground combat simulation. Janus simulates two opposing forces in battle. 
Typically the largest force used is a brigade due to effects on the simulation and ability 
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of force players to command their subordinate forces. These forces are controlled by two 
or more users operating from individual computer terminals. Each terminal is a graphical 
depiction of friendly forces, detected enemy forces, terrain contours, and a variety of other 
useful information. Within Janus, there are thirteen executable FORTRAN programs. 
These programs are divided into three major groups: database creation and management; 
scenario creation, verification, and operation; scenario analysis. [Ref. 1: pp. 1-5] 

2. Areas of Interest 

In order to understand the basics of the improved target acquisition algorithm, it 
is first necessary to comprehend two major concepts of Janus. First, how targets are 
acquired. Second, how a Line Of Sight (LOS) is determined. 

a. Target Acquisition 

The follo\ving is the summarization of A.D. Kellner’s 14 July, 1992 
memorandum for the record on target acquisition in Janus presented in Lieutenant 
Frederick W. Dau’s thesis [Ref 2: pp. 3-7]. 

(1) Background. Acquisition in the Janus model is based on the 
mathematical detection model developed by the Night Vision and Electro-Optics 
Laboratory (NVEOL). This model is based on a concept involving the computation, for 
a specific sensor-target pair, of the number of resolved cycles across a target’s critical 
dimension. 

Imagine a pattern of stripes or bars equal in length and alternating 
in color at the targets location. Let the contrast between the colors of the pattern be the 
same as the contrast between the image of the target and it’s background. The length of 
the pattern is the same as the target’s minimum presented dimension. Slowly decrease 
the width of the strips until the minimum width at which the observer can still distinguish 
the individual stripes is reached. The number of pairs now contained in the minimum 
presented area is called the number of resolved cycles for that target-sensor combination. 

The concept of resolvable cycles is very useful in the computation 
of detection probabilities. The NVEOL model defines two probabilities associated with 
the detection of a given target by a given sensor. First, the Probability of Detection (PD) 
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is that the target will be detected by the sensor given infinite time. This quantity is also 
known as p-infmity. Second, is the probability that the target will be detected during the 
time it is wi thin the sensors’s field of view, given that it can eventually be detected. This 
is called P(t). Both quantities of PD and P(t) are functions of the number of resolvable 
cycles, N, which can be resolved by a given sensor-target pair. The probability that a 
sensor can discriminate the target once detected is also a function of N. 

The portion of the NVEOL model relevant to Janus consist of the 
follovwng three steps: 1) calculate the attenuation of the target’s signature along the LOS 
2 ) given the target’s signature at the sensor, calculate the number of cycles the sensor can 
resolve across the target’s critical dimension 3) given N, determine if the target can be 
detected, acquired, and recognized. 

(2) Signature Attenuation. Signature attenuation between the target 
and the sensor is caused by atmospheric effects as well as objects obscuring the path of 
the LOS which will be called large area smoke. Let: 

St = signature at target 
Ss = signature at sensor 
T1 = transmission of normal atmosphere 
T2 = transmission of large area smoke 

and 

Ss = St * T1 * T2 

For optical sensors, St is the optical contrast of the target which is a part of the master 
database, and thus remains the same for a target during a Janus run. 

(3) Resolvable Cycles. The performance of a sensor is represented 
by a curve of resolvable Cycles Per Milliradian (CMR) as a function of the target 
signature measured at the sensor. This can be expressed mathematically as follows: 

CMR = f(Ss) 
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However there is no analytical equation to describe this function, 
so this function is input in the master database for each sensor as a table of values. 
Entering the table of the specific sensor-target pair vdth the signature at the sensor, Ss, 
produces an output of CMR. Once the number of resolvable cycles is obtained the 
number of cycles actually resolved by the sensor is obtained by: 


N = CMR * 

Range 


(3) 


where 

TDIM = target’s minimum presented dimension in meters 
Range = sensor to target range in kilometers 

TDIM is obtained from the master database for the particular target and range is provided 
by the simulation. 

(4) Acquisition. After the number of cycles resolved on the target 
is known the probability of detection and time till detection, P(t), may be determined. 
The probability of detection given by: 


PD 


CR^ 

1 + CR'^ 


(4) 


where 

W = 2.7 + 0.7*^ 

CR = N/N50 

N = number of resolvable cycles 

N50 = median number of resolvable cycles required for eventual detection 
Note that when N = N50 the equation 4 goes to 0.5, meaning that for a random sample 
of observers, half vdll require less than N50 resolvable cycles to detect the target and half 
will require more. Janus uses the following N50 criteria for detection and subsequent 
target discrimination: 
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1.0 cycles Detection: sensing a foreign object is present 
2.0 cycles Aimpoint: ability to aim at a target 

3.5 cycles Recognition: ability to distinguish target class, such as tank, truck, jeep 
6.4 cycles Identification: ability to classify target as specific member of a class 
At the beginning of a Janus run each sensor-target pair is assigned 
a random value which represents the ability of the sensor to detect the corresponding 
target. This random number is the number of resolved cycles required to detect and is 
called the detection threshold. When N is greater than or equal to the detection threshold 
it is said that the p-infinity test has been passed and that the target may eventually be 
detected by that particular sensor. Once the p-infinity test is passed a value for P(t) is 
determined using the values of CR and PD. This value is compared to another randomly 
drawn number, and if it exceeds this random number then detection or another level of 
discrimination is achieved. 

b. Line of Sight 

Within the DOLOS subroutine, target acquisition cannot occur if targets are 
sufficiently concealed behind terrain features. It is therefore important to verify that a 
LOS between the sensor and target exists before considering target acquisition. Within 
Janus, the subroutine DOLOS is called to determine Probability of Line Of Sight (PLOS). 
Initially DOLOS retrieves sensor and target grid locations and elevations and determines 
a Temporary Probability of Line Of Sight (TPLOS). [Ref. 3: p. 413] 

Within the Janus terrain database, each grid is assigned a density value. 
Assignment of a density value to a grid is determined by surveying the number and height 
of vegetation for each grid. Once a density value is signed, the entire grid will have the 
same height and PLOS. [Ref. 2: p. 8] 

The slope of a line between sensor and target is now determined based on 
X and y coordinates of each. Depending on slope, DOLOS incrementally steps one grid 
at a time starting from sensor and goes toward target. Vertical slope is also calculated. 
At each step, height changes are added to sensor height. In each grid along the path of 
the LOS, HITREE retrieves grid tree height and density values. Tree height is added to 
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a grid s ground elevation and compared to LOS elevation in grid. Termination would 
occur if LOS height is less than grids base elevation. Continuation of LOS would occur 
if LOS height is greater than the grids base elevation, and procedure is repeated. If LOS 
height falls somewhere in between grid elevation and total elevation including obstacles, 
TPLOS is multiplied by the probability of LOS retrieved by HITREE. This repetitive 
procedure is continued until target grid is reached or TPLOS falls below 0.01. This is an 
indication that the LOS has been completely attenuated by the terrain features along the 
path and no longer exists. When DOLOS completes its run, it passes final value of 
TPLOS back to calling routine as PLOS. [Ref. 2: pp. 9-10] 

3. Limitations 

a. Terrain Representation 

Within the Janus database, the low resolution of terrain and objects on it 
are considered a limitation to the realism of the simulation. For the purpose of this thesis 
only terrain, trees, and buildings will be discussed. 

The terrain used in Janus is a digitized representation based on Defense 
Mapping Agency data. As shown in Figure 1 [Ref. 4: p. 6], the graphical representation 
details contour lines, roads, rivers, vegetation, and other obstructions [Ref 5: p. 3 ], 

The horizontal resolution is one hundred meters and vertical resolution is 
ten meters. There are several different sizes of exercise areas to choose from at the 
beginning of a simulation. The area chosen is subdivided into grid cells. These grid cells 
are represented as a flat plate with constant elevation, with constant terrain type. In order 
to go between adjacent cells of different elevation it is necessary to "step up" instead of 
a gradual slope. For LOS calculation it is necessary to linearly interpolate between cells. 
The resolution of this database is considered to be low, and it does not actually represent 
actual objects on the terrain. Vegetation is only modeled as an impediment to LOS 
calculations. Individual bushes or trees are not modeled, and any vegetation shown is 
constant for each grid cell. Buildings are represented only as statistical entities, individual 
buildings cannot be shown. 
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Figure 1: Terrain Representation 
b. Target Representation 

The view presented by the computer are contour maps of the battlefield 
consisting of player’s subordinate combat systems, units, and personnel displayed 
symbolically. Enemy units that can be seen by friendly forces are also shown as symbols. 
[Ref 3: p. 5] 

C. PEGASUS DATABASE 
1. Background 

The Pegasus database or perspective view database, covers a rectangular area of 
Fort Hunter Liggett which covers more than four hundred square kilometers. It is a 







graphical database created from aerial photographs, vegetation heights, and additional 
information required for perspective view generation. The database is organized into tiles, 
blocks and posts, with posts being the smallest element. The resolution considered for 
this thesis is a one square meter post. [Ref 6: p. 3] 

2. Thirty-two Bit Number Representation 

Each post is described by a thirty-two bit binary number. There are nine elements 


to each 32 bit number, as shown in Figure 2 [Ref 6: p. 3]. 
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Element 

Number 

Maximum 


Code 

of bits 

Value 

Description 

ELE 

11 

2047 

Elevation in meters 

EL2 

12 

4095 

Elevation in half meters 

UCI 

2 

3 

Under Cover Index 

NOR 

4 

15 

Surface Normal Indicator 

VGH 

4 

15 

Vegetation Height Index 

VID 

2 

3 

Vegetation ID 

NAT 

1 

1 

Nature Bit 

SSB 

1 

1 

Sun Shade Bit 

GSV 

6 

63 

Gray Shade Value 


Figure 2: Pegasus Database Elements 


Visualization of each element is detailed in Figure 3. Grid elevation is defined by 
ELE and EL2. The NAT element defines whether or not the feature is manmade or 
natural. If feature is natural, value is 1. The UCI element is the height above ground of 
a feature. The NOR element gives an indication of the surface normal. The VGH 
element is the feature height. The VID element when combined with some of the other 
elements is used to determine exactly what the feature is. Colors can be represented by 
the GSV element, and passage of the sun defined by SSB element. [Ref 6: p. 3] This 
32 bit number is stored as a decimal and must be manipulated to extract the desired data. 






Figure 3: Visualization of Pegasus Database Elements 

3. Grid Reference Position 

The reference position of a grid can be determined by manipulating the array 
indexing. As an example, Figure 4 shows a sample 4x5 grid (20 grids, 20 numbers), and 
Table 1 shows a 1x20 array called locate[ ] which represents the 32 bit numbers 
describing each grid. To locate the decimal number describing grid position "A" in 
locate[ ], the following array location reference method is used: 

locate [x * 5 + y] = 2099378 
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Figure 4: Sample Grid 

This method starts counting (with zero) at the bottom left grid and counts up the 
first column, starting again at the bottom of the next column till grid position reached. 
In the example, position "A" is the thirteenth number of the array (2099378). 
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1202 

1202 

1202 

1202 

1202 

1202 

1202 

1202 

1202 

1202 

1202 

1202 

1202 

2099378 

1202 

1202 

1202 

1202 

1202 

1202 


Table 1: Locate[ ] 


D. IMPROVED TARGET ACQUISITION ALGORITHM 

1. Objective 

The objective of the improved algorithm was to develop an improved method of 
target detection and acquisition which utilizes the Pegasus database. By being able to use 
Pegasus, the algorithm should be able to utilize the higher resolution and actually be able 
to determine if lines of sight exist and their quality. [Ref. 2: p. 16] 

2. Accomplishments 

a. Target Representation 

With higher resolution of terrain representation comes the ability to have 
more than one LOS. The target used consists of a square three meters by three meters 
by one meter, and a one by one by one meter block sitting on the top center, as shown 
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in Figure 5 [Ref. 2: p. 28]. Dependent on relative position of sensor and target up to 
eight faces of the target are available for lines of sight. 



b. Obstruction Representation 

Obstructions are based on Pegasus style object representations. With the 
higher resolution, objects can have a wide variety of sizes and shapes. Individual trees, 
and buildings can be distinguished. Figure 6 [Ref. 2: p. 20] shows the representations 
used for obstructions. 

c. Determination of Number of Possible Line’s of Sight 

From a sensor located at a fixed position on the terrain, and a target located 
at another position, subroutine aspectQ is called. Based on the relative position of the 
target to sensor, the number of target faces that are presented to the sensor can be 
determined. There is a possibility of a maximum of eight faces or a minimum of four 
faces that can be presented at a time. By saying "visible" it is only meant that if the view 
between sensor and target is completely imobstructed, this is how many faces could be 
seen. The top surfaces to the target are not considered, nor are the back faces. 
[Ref 2: p. 28] 
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d. Stepping of Line of Sight 

Depending on which distance is larger, the change in the x direction, or the 
change in y direction, one meter steps are taken in that direction. A single block is 
passed through on each step. Figure 7 shows an example of when the difference in x is 
larger than the y, therefore the LOS steps in the x direction one meter at a time. At each 
X coordinate, the y value is found using the y slope and origination point. As shown, the 
dark line represents the true path of the LOS, the shaded boxed show how the LOS steps. 
[Ref 2; pp. 29-30] 
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Figure 7: Stepping of Line of Sight 


E. OBJECTIVE 

The goal of this thesis is to add visualization to the improved target acquisition 
algorithm. By doing this, the data results of the algorithm can be visually confirmed. It 
will also show that it is possible to incorporate existing software into a training 
application with minimal programming experience. There are three major-steps that need 
to be taken in accomplishing this goal. They are: conversion of FORTRAN to C; 
understanding WorldToolKit (WTK); and creating a simulation incorporating the 
improved algorithm. 
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1. Conversion 

The conversion process will involve breaking down FORTRAN code into specific 
functions and correlating these function to C functions. Each C function will then be 
tested as a separate program and then added to a main program. 

2. WorldTooIKit 

WTK will require a thorough understanding of its many functions. Specifically 
for this project: how to create a terrain with objects on it; create objects; and be able to 
move them along the terrain. Additionally, an understanding of how to manipulate 
viewpoints, lighting, sensors, and windows tvill be required. 

3. Simulation 

This will involve combining WTK into the algorithm such that the visual 
representation of the terrain and motion of the target is driven by the improved algorithm. 
The simulation should have a target moving along an obstruction constrained terrain and 
display target data as the target moves. 
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II. CONVERSION OF CODE AND DATA 


A. OBJECTIVE 

The objective in converting the improved target acquisition algorithm from 
FORTRAN to C is to enable incorporation of WTK (programmed in C) into the improved 
algorithm. To simplify further discussions, the improved algorithm will hereafter be 
referred to as either FORTRAN code or C code. 

The objective in converting 32 bit number data is to be able to manipulate specific 
elements. These elements are used to compare LOS Avith terrain features. 

B. CODE CONVERSION 

1. C Programming Basics 

In order to begin conversion from FORTRAN to C, an imderstanding of a few 
basic C programming concepts is required. These basic concepts are as follows: 
preprocessor directives; functions; variables and constants; and pointers. The sample C 
program shown in Figure 8 contains examples of each of these concepts. 

/* Example of Preprocessor Directive */ 

#include <stdio.h> 

/* Example of Defining a Variable */ 
int test; 

main() 

{ 

/* Example of a Function */ 
printf(’\nAnswer = %d\n’, test); 

/* Example of Using a Pointer */ 
testl= &test; 

} 

Figure 8: Basic C Program 
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a. Preprocessor Directives 

After a program has been written, the next step is to compile it. During 
compilation, preprocessor directives tell the compiler to accomplish specific tasks. In the 
example given previously in Figure 8, #include directs the merger of a disk file (specified 
between < >) into the source code by the compiler [Ref 7: p. 90]. This disk file is called 
a header file, by convention it is annotated by the extension .h. When called by the 
compiler, header files help check code for syntax and errors. A required C header file 
is stdio.h, which stands for standard input-output [Ref 7: p. 92]. Stdio.h tells the 
compiler to be prepared for input and output ftmctions in the program. If utilizing math 
functions such as sqrtQ powQ another required header file is math.h. 


b. Functions 

A function is defined as something used to solve a particular programming 



Every C program must have a mainQ function, which marks the point 
where program execution begins and ends. Within mainQ’s open and closed braces ({}), 
execution of program statements that appear first dictate what the program does first. 
Some of the standard functions utilized in the C code were printfO, scanfQ, ceilQ, 
floorO, powO, and sqrtQ- In addition to standard functions, specialized functions can be 
written to accomplish unique programming tasks. Some example of specialized functions 
used in the C code are: terrainQ, compareQ, and aspectQ. Function arguments are 
enclosed between the parenthesis, if any are required. An argument is used to pass to the 
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function anything it needs to complete its task. Examples of arguments are, variables, 
constants, and pointers. At the end of a function the statement return; is used to return 
control back to the calling function. 

c. Variables and Constants 

In order to correctly manipulate data within a program, it must be correctly 
defined within a program. Data is defined as either variables or constants. Variables hold 
different types of data such as characters, integers, or floating point decimals, and can be 
changed. Constants also hold different types of data, but remain the same throughout the 

program. 

There are two types of variables, global and local. Global variables are 
defined outside a function. Problems can arise if a variable is defined as global and the 
same name is used in different program locations, but with different meaning. The value 
of one can be inadvertently changed, causing incorrect answers. Local variables are 
defined within the opening brace of the function, and will only be used in that function. 
[Ref 7: pp. 298-299] 

Local variables can also be defined as automatic or static. The default for 
local variables is automatic. Automatic means that when a function returns to the calling 
function, local variable values within it are erased. Static means that local variables will 
retain their value within a function when it returns to the calling function. 
[Ref 7: p. 312] 

d. Pointers 

A key aspect to programming in C is the capability of variables pointing 
to addresses of other variables. These pointers are variables in themselves and follow the 
same rules which govern variables. So, instead of holding data values, which takes up 
memory, pointers provide a means of accessing and changing data by pointing to the 
address of another variable. There are two pointer operators in C, the & and *. The & 
operator is used to point to the memory address of whatever it precedes. The * operator 
either defines a pointer or dereferences the value of the pointer. Figure 10 illustrates how 
to use these operators. [Ref. 7: pp. 447-450] 
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/* Defines Pointer Called "ptr" */ 
int *ptr; 

/* Defines "test" as an Integer with Value 10 */ 
int test =10; 

/* Points "ptr" to Address of "test" */ 
ptr= «&test; 

Figure 10: Pointer Use Example 

2. FORTRAN to C Conversion Procedure 
a. FORTRAN Code Description 

The FORTRAN code [Ref. 2: pp. 106-118] is organized into a main 
program with one subroutine called aspectO- A flowchart for the FORTRAN code is 
shown in Appendix A. 

The following is a brief description of the logic steps within the FORTRAN 
code. The program starts by declaring variables, reading data from an external file into 
array tile(), and manipulating this data into decimal form. There are ten target locations 
stored in array locate(). DO loop (1) is entered with the maximum number of iterations 
being ten (ten target locations). After retrieving the first target location from locate(), 
subroutine aspectQ is called. Within aspectQ, the number of target faces visible and 
location of these faces, is calculated. These are returned to the main program as values 
of "n" and array vistgt( ). Next DO loop (2) is entered v^dth the maximum number of 
iterations being "n". Within this DO loop, an IF loop is entered. IF the slope of the line 
between target and sensor is greater in the x direction then xstep operations are 
performed. If slope is greater in the y direction, then ystep operations are performed. 
Depending on which was used in a particular iteration, both xstep and ystep operations 
enter another IF loop. IF a LOS exists then calculations are performed and DO loop (2) 
is re-entered. IF the LOS is terminated due to an obstruction DO loop (2) is re-entered 
without calculations. After "n" faces of a target is tested, DO loop (1) is re-entered for 
the next target location and the procedure is repeated. 
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b. Conversion 

Within the main section of the FORTRAN code there are four different 
functional areas. The functional areas are: header operations; stepping in x direction; 
stepping in y direction; and calculations. Each of these four areas and the subroutine were 
converted to C separately, tested, and then one by one incorporated into a main C 
program. 

Initially it was hoped that there could be a line for line translation from 
FORTRAN to C. This became unreasonable due to some procedural differences in code 
translation. First, bitwise manipulation differed due to not having a straight translation 
for the FORTRAN function ibitsQ. In C, there are two bitwise operators called AND and 
SHIFT. Second, mathematical functions differed due to not having a straight translation 
for the FORTRAN math function nmtQ, which round up or down to the nearest integer. 
In C, two functions had to be set up utilizing function ceilQ (rounds up) and function 
floorO (rounds down). Third, relational operator structures differed due to C not using 
numbered loops which can use a continue statement to return to the beginning of the 
loop. C uses a goto statement to return to beginning of a loop. 

It became clear that with C, there was an opportunity to organize the C 
code into specific function calls. The areas that the FORTRAN code were broken into 
for translation, now became C functions. Additionally, other areas within the FORTRAN 
code main program were also broken into C functions, such as compareQ and displayQ- 

Testing involved injecting test print statements into the FORTRAN code 
at key locations. Then entering specific variable values and running that section of C 
code. Finally, comparing C code results with output from FORTRAN code. 

c. C Code Description 

Once each of the separate sections of C code were tested satisfactorily, each 
was individually incorporated into a main program. The final C code was then tested and 
compared to FORTRAN code results. This conversion was completed satisfactorily. See 
Appendix B for flowchart of C code organization. 
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The following is a brief description of the logic steps for the C code. The 
program starts by declaring variables, reading data from an external file into array tile[ ], 
and mampulating this data into decimal form. FOR loop (1) is entered with the maximum 
number of iterations being ten (ten target locations). After retrieving the first target 
location from locate[ ][ ], function aspectQ is called. Within aspectQ, the number of 
target faces visible and location of these faces, is calculated. These are retmued to the 
main program as values of "n" and array vistgt[ ][ ]. Next FOR loop (2) is entered with 
the maximum number of iterations being "n". Within this FOR loop, an IF loop is 
entered. IF the slope of the line between target and sensor is greater in the x direction 
then xstep operations are performed. Within the xstep operations, functions nintyQ and 
compareQ are called. If slope is greater in the y direction, then ystep operations are 
performed. Within the ystep operations functions nintxQ and compareQ are called. 
Depending on which was used in a particular iteration, both xstep and ystep operations 
enter another IF loop. IF a LOS exists then calculations are performed (continue;) and 
FOR loop (2) is re-entered. IF the LOS is terminated due to an obstruction function 
displayQ is called and FOR loop (2) is re-entered without calculations (finish;). After 
"n" faces of a target is tested, FOR loop (1) is re-entered for the next target location and 
the procedure is repeated. 

C. DATA CONVERSION 

1. 32 Bit Number Conversion 

The 32 bit numbers are stored as decimals and must be manipulated in order to 
extract the desired data. In C, the AND(&) and SHIFT(») functions make it possible 
to emulate the FORTRAN function ibitsQ. The AND function is a bitwise operator and 
makes a bit by bit comparison of the number presented. The SHIFT function performs 
a left or right shift of bits within a binary nmnber. An example would be to extract the 
NAT element (which is the 7th element) from a 32 bit number located in array test[ ]. 
First, test[ ] is ANDed vvdth 128 (bintest[ ]=test[ ] & 128). The number 128 being base 
ten equivalent of binary number 10000000. The result (bintest[ ]) will be a binary 
representation of the first 7 bits of the 32 bit number. This number is then SHIFTed right 
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7 bits (nat[ ]=bintest[ ] » 7) leaving the bit that represents the NAT element. 
[Ref. 7: pp. 196-203] 

2. Terrain Modeling 

In order to test the C code visually with WTK, the battlefield used to test the 
FORTRAN code will be re-created. The terrain for this battlefield consists of flat ground, 
small trees, large trees, and a small building. Each of these objects has a known height 
and undercover index since the higher resolution Pegasus database was used. The actual 
creation of the battlefield will be discussed in a later chapter. 

3, Program CONVERT.C Description 

To facilitate the creation of the test battlefield, program CONVERT.C 
[Ref 2; pp. 101-102] was also converted from FORTRAN to C. The flowchart for 
CONVERT.C is shown in Appendix C. 

The following is a brief description of program CONVERT.C. The program starts 
by declaring variable and arrays. The user is then prompted to input how many 32 bit 
numbers to be created, this input is read as ans from the keyboard. FOR loop (1) is 
entered with maximum iterations of ans. Next, FOR loop (2) array t[ ] is initialized to 
zero. Next, FOR loop (3) is entered with iteration counter i and maximum number of 
iterations of thirty-one. For each i from 1 to 9 an IF loop is entered. For purposes of 
brevity only the first IF loop will be described. IF i equals 1 then variable bitO equals 
0 and the user is prompted to enter the value of GSV. This input is read from the 
keyboard as rem. If the number entered is equal to zero, then the next IF loop is entered. 
For every IF loop, if the number entered is not zero then the number is converted into 
binary. The result is a 32 bit binary number describing a one meter square of terrain. 
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in. WORLDTOOLKIT 


A. OBJECTIVE 

The objective with regard to the utilization of WTK is to create a virtual world 
which will look like the test battlefield. Within the virtual world it will be necessary to 
represent targets and obstructions both realistically and in the form that the C code sees 
them. 

B. WORLDTOOLKIT PROGRAMMING BASICS 

1. Overview 

WTK is a commercially available software program developed by SENSES 
Corporation, and is essentially a library of C functions. It provides an opportunity to 
create three dimensional (3-D) simulations and models with limited C programming skills. 
This is accomplished by adding specific WTK functions and their arguments to C source 
code. These WTK functions are broken down into classes. Assigned to each function 
class are subroutines identified by a handle. An example of the graphical object class 
handle would be WTobject_new. All functions require objects of a class to be pointed 
to as the first argument. As an example, WTobject *cube creates a new object and 
returns a pointer to cube. Pointers were discussed in the previous chapter. Somewhere 
later in a program, cube=WTobject_newO would be used to create a new object. In the 
next several sections, the major classes and objects utilized in WTK for this thesis will 
be discussed. 

2. Universe Class 

In its most basic sense, the universe created in WTK is a container4;Ref 9: p. 2-1]. 
Inside the universe, all objects created are either stored (static) or mampulated (dynamic). 
Since only one universe can exist at a time, pointers are not required as a first argument 
when creating or loading a umverse. The umverse function handles are what is used to 
control simulation loop repetition activity. An important part of the flexibility in using 
WTK is the user input to the universe action function as illustrated in Figure 11 

[Ref 9; p. 2-8]. 
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Figure 11: WTK Simulation Loop 


3. Graphical Object Class 

Graphical objects are the building blocks of WTK [Ref. 9: p. 3-1]. They provide 
the user with many options in which to manipulate the simulation. Graphical objects can, 
interact with the user, interact with other objects, be hierarchial organized, have their 
motion effected by sensors, have tasks assigned, and have data associated to them 
[Ref 9: p. 3-1]. For this thesis, objects were created from internal predefined object types 
using WTK functions, and by importing DXF format files generated from Autodesk. By 
convention, WTK uses the right hand rule for defining the world coordinate reference 
frame [Ref 9: p. 3-7]. The world coordinate reference frame is fixed in space and 
therefore independent of any objects within the umverse. However, a local coordinate 
reference frame can be created by determining the objects vertices and setting it to these 
planes. The follovdng examples of graphical object class handles used in this thesis, 
WTobject_getposition(), WTobject_newblock(), WTobject_newsphere(), 
WTobject_changecolorO, and WTobject_setposltion(). 
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4. Terrain Objects 

Terrain objects represent landscape, and WTK can create three types, flat, random, 
and data generated. The test battlefield will be created as a flat 35x50 (square meters) 
terrain object. By default, terrain objects are given a checkerboard appearance to aid 
perspective view visualization. The default local reference frame for terrain objects is 
taken to be the same as world coordinate reference frame. Terrain object handle 
WTterram_flatO was used to create the flat terrain test battlefield. [Ref 9: p. 6-1] 

5. Textures 

Textures are equivalent to applying paint to surfaces of an object. This is done 
in order to im prove realism and provide a means to conserve modelling labor and 
rendering speed by allowing a single object to be painted instead of modeling all of its 
3-D details. Textures are obtained from video images or synthetically and are identified 
by the extension .rgb. Wood texturing was applied to cylinders to appear as tree trunks. 
Grass texturing was applied to spheres to appear as leaves. Building window texturing 
was applied to the small building to improve its realism. The texture handle 
WTobject_settextureO was used to apply textures to objects. [Ref 9: pp. 8-1,8-2] 

6. Light Objects 

WTK has two kinds of lights, direct and ambient [Ref 9: p. 9-1]. Ambient light 
is background light and it lights objects equally regardless of position or orientation. 
Directed light can be directed in a particular direction to produce shadows and contrast 
between objects. More than one light may be added to a simulation but, the more lights 
the greater impact on performance due to shading computations. The light object handles 
\VTlight_newO and WTlight_setambientO were used to create a directed light source 
and set the ambient light source, respectively. 

7. Sensor Class 

Sensors allow the user to interact with the simulation directly. They are used to 
generate positional and orientational data by reading inputs from the real world 
[Ref 9: p. 10-1]. A Spaceball by Spaceball Technology was created as a sensor and used 
to move a viewpoint through the test battlefield. The sensor handle 


27 


WTsensor_setsensitivityO set Spaceball sensor sensitivity to a default value and 
spaceball=WTspacebaIl_newO defined the Spaceball as a new sensor. 

8. Viewpoints 

In a window, the universe is drawn from parameters set to a viewpoint 
[Ref. 9: p. 11-1]. The major parameters are defined as, position, orientation, and 
direction. They allow the user to place viewpoints anywhere in the universe and look in 
specific directions and orientations. The viewpoint handle \VTviewpoint_addsensorO 
was used to attach a viewpoint to the Spaceball. To create a new viewpoint, the 
viewpoint handle WTviewpoint_newO was used. 

9. Path Class 

A path is a combination of nodes which store a specific locations position and 
orientation data [Ref. 9: p. 13-1]. An object or viewpoint can be attached to a path, and 
moved from node to node. The more nodes, the smoother the transition between nodes. 
There is the capability to interpolate between nodes, which is especially effective when 
the path follows a curve. Paths can also be recorded, edited, saved, and played back 
[Ref 9; p. 13-1]. Path class handle WTpath_loadO was used to load external path files 
identified by extension .pth, which were created by an external program. This external 
path program will be discussed in the next chapter. 

10. Window Class 

A window object is a region of the screen where viewpoints are to be displayed. 
Several windows can be created, each with a different viewpoint attached. These 
windows can be created and deleted at any time during the simulation. The location and 
size of the windows is specified in the function arguments. The window class handle 
WTwindow_newO was used to create new windows. [Ref 9: p. 15-1] 
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rV. SIMULATIONS USING WORLDTOOLKIT 


A. OBJECTIVE 

The simulations objective is to demonstrate that WTK can be incorporated into the 
C code. In doing so, they will also show what it is C code does, and visually validate the 
output. 

Creating simulations will comprise of two steps and two different test battlefields. 
First, converted programs CONVERT.C and BTLFLD_TERR.C will be used to create a 
test battlefield with ground, obstruction, and target data. Second, WTK will create a 
virtual world test battlefield which will be incorporated into C code. 

Three simulations were created to meet required objectives. They are PROGl.C, 
PROG2.C, and PROGS.C. This chapter will describe methodology used to create each 
simulation and their major fimctions. 

B. TEST BATTLEFIELD CREATION 

1. Test Battlefields 

The test battlefields used in this thesis are similar to the 35x50 grid on which 
ground, obstructions and target were placed in ONEMETER.F. The only difference being 
actual location of targets. Figure 12 shows grid (ground), location of obstructions, and 
locations of target used in C code. Since there are actually two types of test battlefields 
that need to be constructed, the following is a brief description of both, 
a. C Code Test Battlefield 

The C code test battlefield is a database of Pegasus numbers that C code 
will read, manipulate, and then use in comparison with calculations of LOS. This 
database is created in two steps using two different programs. From program 
CONVERT.C, 32 bit Pegasus numbers are created for flat ground, three meter tall trees 
with no undercover index, eight meter tall trees with undercover index of one meter, and 
an eight meter tall small building (trees and building were shown in Figure 6). These are 
the only obstructions considered for this thesis. 
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Figure 12: Test Battlefield 


Program BTLFLD_TERR.C (also converted from FORTRAN to C) creates 
a 1x1750 (35x50) database array of Pegasus numbers obtained from CONVERT.C. 
Within BTLFLD_TERR.C, the entire database is first initialized as flat ground, then user 
is queried whether a three meter tree is to be placed on the flat ground. If answer is yes, 
then user is prompted to enter coordinate location. This is repeated until no more three 
meter trees are desired, same procedure is then repeated for eight meter trees and small 
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buildings. For each obstruction entered, the flat ground 32 bit number is replaced by a 
new value. BTLFLD_TERR.C utilizes the array location referencing method previously 
discussed in Chapter 1 for placing appropriate 32 bit number in the database. Output 
from BTLFLD_TERR.C is written to an external data file called BTLFLD_TERR.DAT. 
The flowchart and code for BTLFLD_TERR.C are shovra in Appendix F and Appendix 
G, respectively. 

b. WTK Battlefield Terrain 

The other test battlefield created is the one that WTK will visually display 
in the virtual world. From the library of WTK functions, the 35x50 flat grid (ground) is 
created. Located on the ground in same coordinate locations as C code battlefield, are 
same size trees and building. For different simulations, obstructions will be displayed 
differently. In PROGl.C and PROG2.C trees and building shapes will be created to 
appear as representative of real trees as possible. Additionally, in PROGl .C, textures will 
be applied to add realism. In PROG3.C, trees and building will be displayed as C code 
sees then, i.e., cubed entities. 

2. Battlefield Targets 

There are also going to be two types of target. C code will see the cubed target 
shown in Figure 5, and WTK will display a tank, shown in Figure 13 and the cubed 
target. To display targets, WTK loads a .dxf file to render the tank for PROGl.C and 
PROG2.C and a .dxf file to render the cubed target for PROG3.C. 



Figure 13: Tank Target 
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C. SIMULATION PROGRAMS DESCRIPTION 

1. Overview 

Each of the three programs created is essentially the same C code beginning, with 
WTK successfully incorporated as a function and LOS calculations imbedded within 
WTK. There are subtle changes to each program in their C code and each has major 
differences in what WTK displays. 

Program PATH.C is an external WTK program that is used to create a user 
defined path. At screen prompts, user inputs path node locations and rotation. After 
entering all required nodes, user can select a method of interpolation to smooth out 
motion along any curves in path. Output from PATH.C [Ref 10: pp. 69-75] is a file 
designated by extension .pth. The flowchart for PATH.C is shown in Appendix E. This 
program is used to create paths used in PROG2.C and PROGS.C. 

Program PROGl.C utilizes an internal array of target locations (locate[ ]) which 
WTK uses to place the tank. The user manually presses a Spaceball button to move the 
tank to predetermined positions behind the trees and building, while displaying target data 
output at each prompt. There is an option to add viewpoints of universe from two 
additional windows, which can also be deleted at any time. The default window view is 
attached to the Spaceball, view from window one is from perspective of observer located 

at position (0,0), and view from window two is from back right comer looking toward 
sensor. 

Program PROG2.C does not utilize an internal array of target locations, instead 
it uses WTK function WTobject_getpositionO to obtain tank locations as the tank follows 
a predetermined path which was created using program PATH.C. The movement of the 
tank requires no user input other than to start motion by pressing a Spaceball button. In 
addition, output is continuously displayed to the screen. The same window options exist 
as with PROGl.C. 

Program PROG3.C is similar to PROG2.C except it has a cubed target following 
a slightly different predetermined path created using PATH.C. Additionally, the default 
window viewpoint is different, and there is only option for one additional window. The 
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path is essentially the same, but the cubed target does not have any rotation i.e., front face 
remains aligned with the x axis. The default view is from observer perspective located 
at position (0,0) and view from additional window is an overhead view. 

The following three sections are a description of major functions that take place 
in each program. The flowchart and code for PROGl.C are shown in Appendix F and 
G, respectively. The flowchart and code for PROG2.C are shown in Appendix H and I, 
respectively. The flowchart and code for PROG3.C are shown in Appendix J and K, 
respectively. 

2. Program PROGl.C 

Program PROGl.C starts by declaring global variables, pointers, windows, and 
viewpoints. Function mainQ is entered and Pegasus database data is read into array tile[ ] 
from external file BTLFLD_TERR.DAT. This data is then manipulated by AND and 
SHIFT operators (previously discussed) ending with array tile[ ] being converted into 
various element arrays uci[ ], vghindex[ ], vgh[ ], vid[ ], nat[ ], and elev[ ]. These 
element arrays will be used to compare terrain data with each LOS to determine if LOS 
passes through a post. Function terrainQ is then called, which for all practical purposes 
is WTK. The first action in terrainQ is to call function my_action0. Within 
my_action0, each possible action prescribed by pressing a Spaceball button is defined. 
Simulation will begin if Spaceball button five is pressed, since this is the most important 
button, its actions will be detailed closer. Once button five is pressed, function tgtxtytQ 
is called to determine target position location by reading array locate[ ][ ]. Based on this 
data, a rotational value is assigned for rotating of target at a specific location. Next, 
function losQ is called, with first action being to call function aspectQ and determine 
number of faces presented for detection and location of these faces. After returning to 
losQ with this data, each LOS from sensor to target face is stepped post by post. The 
direction of motion of LOS from post to post is determined in part by calculations 
involving functions nintxQ and nintyQ. In each target face LOS iteration, function 
compareQ is cadled to compare LOS data to terrain data from various element arrays. 
The end result from losQ is the number of LOS, range to target, percent of faces viewed. 
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and area of target viewed. After returning to my_action() from losQ, function datatgt() 
IS called to display the LOS data to screen. Output data from PROGl.C is shown in 
Table 2. Control is then returned back to terrainQ. Back in terrainQ, function treeQ 
is called and trees are created from data read from external data file TREE.DAT. Each 
tree consists of a stretched sphere attached to a cylinder. Texturing is applied to trees to 
enhance authenticity. After returning to terrainQ, building is created, textured, and 
positioned, sensor is created and positioned, and tank is loaded from external file 
TANK.DXF. Finally, WTK creates universe and all objects in it. The next time 
Spaceball button five is pressed, universe data is updated to show tank in its new position 
and target data printed to screen is also updated. Simulation ends when Spaceball button 
eight is pressed at which time control is returned to mainQ and program PROGl.C ends. 
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3. Program PROG2.C 

Program PROG2.C starts by declaring global variables, pointers, windows, and 
viewpoints. Function main() is entered and Pegasus database data is read into array tile[ ] 
from external file BTLFLD_TERR.DAT. This data is then manipulated by AND and 
SHIFT operators (previously discussed) ending v^th array tile[ ] being converted into 
various element eirrays uci[ ], vghindex[ ], vgh[ ], vid[ ], nat[ ], and elev[ ]. These 
element arrays will be used to compare terrain data with each LOS to determine if LOS 
passes through a post. Function terrainQ is then called, which for all practical purposes 
is WTK. The first action in terrainQ is to call function my_actionO. Within 
my_actionO, each possible action prescribed by pressing a Spaceball button is defined. 
Simulation will begin if Spaceball button five is pressed, since this is the most important 
button, its actions will be detailed closer. Once button five is pressed, the tank is attached 
to a path called tnkpth, this path is then started. Next, depending on data retrieved from 
WTobject_getpositionO matching a predetermined location, function tgtposnQ is called. 
Within tgtposnQ, the targets position is determined, and function losQ is called. Within 
losQ, the first action is to call function aspectQ to determine number of faces presented 
for detection and location of these faces. After returning to losQ with this data, each 
LOS from sensor to target face is stepped post by post. The direction of motion of LOS 
from post to post is determined in part by calculations involving functions nintxQ and 
nintyQ. In each target face LOS iteration, function compareQ is called to compare LOS 
to terrain data from the various element arrays. The end result from losQ is number 
of LOS, range to target, percent of faces viewed, and area of target viewed. After 
returning to tgtposnQ from losQ, function datatgtQ is called to display LOS data to 
screen. Output data from PROG2.C is shown in Table 2. Control is then returned back 
to terrainQ. Back in terrainQ, fimction treeQ is called and trees are created from data 
read from external data file TREE.DAT. Each tree consists of a stretched sphere attached 
to a cylinder. Texturing is not applied to the trees in this simulation. After returning to 
terrainQ, building is created and positioned, sensor is created and positioned, tank is 
loaded from external file TANK180.DXF, and external tank path TANK.PTH is loaded. 
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Finally, WTK creates universe and all objects in it. The universe is updated continuously 
while the tank follows the path and the target data printed to screen is also updated 
continuously. The simulation end when Spaceball button eight is pressed at which time 
control is returned to mainQ and program PROG2.C ends. 

4. Program PROG3.C 

Program PROGS.C starts by declaring global variables, pointers, windows, and 
viewpoints. Function mainQ is entered and Pegasus database data is read into array tile[ ] 
from external file BTLFLD_TERR.DAT. This data is then manipulated by AND and 
SHIFT operators (previously discussed) ending with array tile[ ] being converted into 
various element arrays uci[ ], vghindex[ ], vgh[ ], vid[ ], nat[ ], and elev[ ]. These 
element arrays will be used to compare terrain data with each LOS to determine if LOS 
passes through a post. Function terrainQ is then called, which for all practical purposes 
is WTK. The first action in terrainQ is to call function my_actionQ. Within 
my_actionQ, each possible action prescribed by pressing a Spaceball button is defined. 
Simulation will begin if Spaceball button four is pressed, since this is the most important 
button, its actions will be detailed closer. Once button four is pressed, cube target is 
attached to a path called tnkpth, this path is then started. Next, depending on data 
retrieved from WTobject_j;etpositionQ matching a predetermined location, function 
tgtposnQ is called. Within tgtposnQ, targets position is determined, and frmction losQ 
is called. Within losQ, the first action is to call function aspectQ to determine the 
number of faces presented for detection and the location of these faces. After returning 
to losQ with this data, each LOS from sensor to target face is stepped post by post. The 
direction of motion of LOS from post to post is determined in part by calculations 
involving functions nintxQ and nintyQ. In each target face LOS iteration, function 
compareQ is called to compare LOS data to terrain data from the different arrays. The 
end result from losQ is number of LOS, range to target, percent of faces viewed, and area 
of target viewed. After returning to tgtposnQ from losQ, function datatgtQ is called to 
display the LOS data to screen. Output from PROG3.C is shown in Table 2. Control is 
then returned back to terrainQ. Back in terrainQ, building is created and positioned. 
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sensor is created and positioned, cube target is loaded from external file CUBETGT.DXF, 
and external tank path CUBE.PTH is loaded. The trees are then created from internal 
WTK object functions. Each tree consists of cubes arranged to represent Figure 6. 
Finally, WTK creates universe and all objects in it. The universe is updated continuously 
while the cube target follows the path and the target data printed to screen is also updated 
continuously. The simulation end when Spaceball button eight is pressed at which time 
control is returned to mainQ and program PROGS.C ends. 

D. TERRAIN VARIATIONS 

1. Existing Ground Elevation Representation 

A limitation to simulation realism is WTK representing all ground elevations to 
be flat. Within WTK there are two additional ways of representing terrain groxmd, 
randomizing ground elevation heights and reading a data file to generate ground elevation 
heights. Both methods still produce a terrain grid that has a checkerboard appearance. 
The latter of these two methods is an improvement and was researched to try and develop 
a method of improving the reality of groimd elevation visualization. 

2. U.S. Geological Survey Terrain 

The ground visualization improvement method researched involved trying to obtain 
existing groimd elevation data from the U.S. Geological Survey (USGS). The USGS has 
two types of digital cartographic/geographic data files of possible interest. They are 
Digital Line Graph (DLG) files and Digital Elevation Model (DEM) files. Of the two 
types, DEM files represent the greatest potential for improving WTK ground visualization. 
Figure 14 shows an example of what a DEM can display. [Ref 11: p. 1] 

A DEM consists of an array of elevations that are referenced in the UTM 
coordinate system. Of several different size DEM files available, the 7.5 minute 
quadrangle was chosen. A 7.5 minute DEM is a 7.5x7.5 minute block of data generated 
from contour maps or scanning photographs. The data is organized from south to north 
in profiles that are then ordered west to east. The spacing between profiles is 30 meters. 
Figure 15 shows how a 7.5 minute DEM is organized. [Ref. 11: pp. 2-4] 
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Figure 14: DEM Example 
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Type B records contained in the DEM. Type B records contain some header information 
about the profile followed by elevation data. Type C records contain statistical 
information about the accuracy of the data. The elevation information in the Type B 
records is what is needed by WTK. [Ref. 11: p. 15] 

A 7.5 minute DEM was transferred from a USGS nine track magnetic tape onto 
an IRIS Indigo Workstation. A FORTRAN program was written to attempt to extract just 
the elevation data from the Type B records and put it in a format that WTK could read. 
Unfortunately due to time constraints, this effort was not able to be completed. The 
attempts to date had been unsuccessful. 
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V. DISCUSSION 


This thesis has proven the capability of incorporating a commercially available 
visualization software program (WTK) into an existing training algorithm (C version of 
improved target acquisition algorithm). By successfully creating simulations with WTK 
incorporated into the C code, output data from the improved algorithm can now validated 
visually. The visualization of the improved algorithm also proves that the higher 
resolution Pegasus database can significantly improve the way Janus detects and acquires 
targets. This is accomplished by giving it the ability to have more than one LOS between 
sensor and target. 

During the initial steps of learning C programming there were some lessons 
learned that are worthy of mentioning. First, verify that every C command ends with a 
semicolon (;). During compiling, errors will be created in lines below the missing 
semicolon. This gives an indication that there is a severe problem with a majority of the 
program, when in fact only one item is missing. Second, the importance of correctly 
defining variables as local or global cannot be understated. A thorough understanding of 
variables to be used and their interaction between different functions is a necessity. 
Finally, there must be a complete understanding of any unique functions that need to be 
translated. As an example, in order to translate the FORTRAN function ibitsQ, and 
imderstanding of binary numbers is required. This function first takes a decimal number 
and converts it to binary. Then depending on function arguments, extracts a specified 
number of bits, starting at a specified bit, and converts this binary number back into 
decimal form. The C equiv 2 dent to ibitsQ are the bitwise operators AND and SHIFT, 
previously discussed in Chapter II. 

Programming in WTK required extensive use of the reference manual. The 
reference manual lists the library of functions within WTK and is very specific in their 
use. However, the proper arguments required to successfully utilize a function requires 
additional understanding of how WTK uses these arguments. As an example, if using 
WTobject_moveO to move an object, one of the arguments is WTpq which is used to 
describe translation and rotation. If using WTobject_translateO to move an object, one 
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of the arguments is WTp3, which describes an amount of relative motion. It can be 
confusing that the object is being moved in essentially the same fashion, however WTK 
needs the different arguments to complete the task. 

An important factor in the realism of a simulation is object speed and smoothness 
of motion. In PROG2.C and PROG3.C both targets move along a path. Having the 
targets moving at a constant speed and without hesitation at nodes does add realism to the 
simulation. When moving along a path, the number of interpolation points between nodes 
directly impacts the smoothness of motion. Several factors effect the speed of objects 
moving along a path in WTK. The largest impact on speed comes from adding additional 
windows to the simulation. In PROG2.C and PROG3.C, if viewing target motion from 
just the default window, adding the sensor view window slows target motion significantly. 
To a smaller degree, applying textures to object faces slows speed down, as does loading 
a large object from an external file. There are ways to overcome the last two 
degradations in speed. When applying textures, only apply to sides of objects that will 
be seen. For loading large objects, in the arguments for loading an external object there 
is a scaling factor that can reduce the size of what is rendered. A factor in the speed not 
related to WTK directly is the speed of the workstation being used to run the simulation, 
the faster the better. 

In the C code, only vertical faces of the target are considered for detection. 
Horizontal faces need to accounted for in both detection and as part of the total area 
presented for targeting. This is directly tied with the need to detect and acquire targets, 
moving on a non-flat terrain, in which horizontal faces may be presented for viewing, or 
with a sensor located above or below the target. Either way, an improved method of 
geometrically representing the target is needed to improve the C code to account for 
additional views of the target. A possible way to make this improvement is to change 
how targets are represented. At present, targets are not represented by Pegasus style 
numbers, but as fixed values within the C code. In order to more effectively use the C 
code, target representation could be added to the terrain description using Pegasus 
numbers. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

• Both C and WTK have the capability of being utilized with minimal prior 
programming experience. 

• The improved target acquisition algorithm has been successfully converted 
into C. 

• WTK has been successfully incorporated into the C version of the 
improved algorithm. 

• Simulations created visually validate output data by showing there are 
more is one LOS when using a terrain described by the higher resolution 
Pegasus database. 

• WTK can be used to add visualization to algorithms that produce positional 
information about an object. 

• Visual validation of Pegasus capabilities to improve Janus by having more 
than one LOS. Improved algorithm proven to have potential to replace 
DOLOS subroutine. 

B. RECOMMENDATIONS 

The use of WTK in the improved target acquisition algorithm has shown visually 
that the improved algorithm and Pegasus database could enhance Janus by improving 
scenario realism. The following are areas which could positively impact Janus: 

• Improve existing WTK simulations by, using non-flat terrain, targets 
represented by Pegasus numbers, and have both sensor and target moving. 

• Incorporate improved algorithm into Perspective View Generator model. 

• Incorporate improved algorithm into Janus. 
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APPENDIX A. FLOWCHART ONEMETER.F 
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APPENDIX B. FLOWCHART C CODE 








END IF 









APPENDIX C. FLOWCHART CONVERT.C 
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FALSE 


IF 

ans = 1 


TRUE 
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APPENDIX E. FLOWCHART PATH.C 


Header 

Operations 


CALL 

Function 

GETCHAR 


CALL 
Function 
NEW PATH 


CALL 
Function 
GET PTHNAME 


CALL 
Function 
GET COORD 


ANOTHER POINT: 


CALL 

Function 

GETCHAR 
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APPENDIX G. PROGRAM PROGl.C 


/* PROGRAM PROGl.C */ 




/* This program calculates Line Of Sight (LOS) data and visualizes a target moving*/ 
/* through a 35x50 grid using a database of Pegasus numbers and is designed to */ 
/* incorporate attenuation by vegetation. The main section of this program calls */ 
/* function terrainQ which is used to start WorldToolKit and create a universe */ 
/* where there is a flat terrain with trees and a building located on it. The trees and*/ 
/* building are represented as close approximations to real objects. The simulation */ 
/* has the target moving behind the trees and building by manually pressing the */ 
/* spaceball. Each press of spaceball button FIVE moves the target one position. */ 
/* Function terrainQ calls function losQ which is used to calculate target data */ 


^****:(ci|t****:(cit!**l|eH:*****i|c****ic**l|c***i|c***l|c**j|c****j|c*****j|tiK***:(ti|cK:*i|t:(c**:(t**j|c**^ 


/* Standard C and WorldToolKit header files */ 
#include <stdio.h> 

#include <math.h> 

#include"wt.h" 

#include"wt.p" 


/* Defines a pointer spaceball to structure type WTsensor */ 
static WTsensor *spaceball=NULL; 
static WTsensor *mouse=NULL; 


/* Calls function treeQ but does not pass or return any values */ 
static void treeQ; 

/* Defines windows and viewpoints */ 

static WTwindow *winl, *win2; 

static WTviewpoint *obJviewl, *objview2; 

/* Defines objects */ 

WTobject *bldg, *copy, *cyl, *original, *sensor, *sphere, *tank, *terrobj; 

/* Defines pointers to WTp3, WTq, and WTpq structures */ 

WTp3 at,dp 1 ,dp2,dp3 ,dp4,dp5,dir,factors,p,p 1 ,p2,ppp 1 ,ppp2,pt; 

WTq ppl,pp2; 

WTpq model view; 


/* Defines light object to be a pointer to type WTlight */ 
WTlight *mylight; 
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/* Initialize arrays and declares variables */ 

int ans,c,cxt,cyt,ho,ht,i,ix,iy,idx,idy,istart,istop,j,n,nolos,prcnt,xs,xt,xmax,xmin,xstart,ys; 
int yt,y,max,ymin,ystart,zs,zt,zdirt,ztree,binelev[ 1750],binnat[ 1750],binuci[ 1750]; 

int binvghindex[ 1750],binvid[ 1750],elev[ 1750],locate[ 12][3],nat[ 1750],realvgh[ 10 ]; 
mt tgt[17][5],tile[1750],uci[1750],vgh[1750],vid[1750],vghindex[1740],vistgt[9][9]; 
float aproj,atten,attenf,dx,dy,dz,denfol,dist,r,rad,rdx,rdy,row,rdns,range; 
float totarea,visaproj,x,y,y_rotate,z,zx,zy,mdata[7][3]; 

/* Standard C file pointers */ 

FILE *fp; 

FILE *fpl; 

main() 

{ 


/* Reads database information into array from data file "btlfld_terr.dat" */ 
fy=fopen("btlfld_terr.dat",''r"); 
for (i=0; i<=1749; i-H-) 


{ 

fscanf(fp," %d", &tile[i]); 

} 

fclose(fy); 

/* Assigns 1 meter of foliage an attenuation of 30% of the LOS */ 
denfol=0.3; 

/* The vegetation height from Pegasus has values of 0-15, each of these values 
represents a particular height or range of heights. The following is used to correlate 
the vgh value to a meaningful height */ 
realvgh[0]=0; 
realvgh[l]==0; 
realvgh[2]=l; 
realvgh[3]=2; 
realvgh[4]=3; 
realvgh[5]=4; 
realvgh[6]=5; 
realvgh[7]=8; 
realvgh[8]=10; 
realvgh[9]=15; 
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realvgh[10]=20; 

realvgh[ll]=25; 

realvgh[12]=30; 

realvgh[13]=35; 

realvgh[14]=40; 

realvgh[15]=47; 

/* Once the database for the grid desired has been read into an array, the components 
of information are extracted from the 32 bit number using the AND and SHIFT 
functions. The groups of information of use in the program are placed in their own 
arrays for rapid recdl during calculations as follows: 


elevation of highest point in grid - ELEV 

under cover index - UCI 

converted vegetation height - VGH 

vegetation ID * VID 

nature bit - NAT */ 

for (i=0; i<=1749; i-H-) 


{ 

binuci[i]=tile[i] & 786432; 
binvghindex[i]=tile[i] & 15360; 
binvid[i]=tile[i] & 768; 
biimat[i]=tile[i] & 128; 
binelev[i]=tile[i] & 4292870144; 
uci[i] = binucip] » 18; 
vghindexp] = binvghindex[i] » 10; 
vgh[i]=realvgh[vghindex[i]]; 
vid[i] = binvidp] » 8; 
nat[i] = biimatp] » 7; 
elev[i] = binelev[i] » 21; 

} 

/* This program is currently written to run in a stand alone mode. Sensor information 
is entered from the keyboard, and target data is read from an array to simulate a 
moving target. Inputs sensor location and height */ 

printf("\nThe Default Sensor Coordinates are xs = 0, zs = 0"); 
printf("\nand hs = l\n"); 

printf("\nDo you wish to Change these values? l=Yes, 2=No\n"); 
scanf(" %d",&ans); 

if (ans = 1) 

{ 
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BEGIN: 


printf("\nEnter Sensor X Coordinate (X,Y)\n"); 
sc2inf("%d,%d",&xs,&ys); 
printf("\nEnter Sensor Height\n"); 
scanf("%d",&ho); 

printf("\nAre You Sure? l=Yes 2=No \n"); 
scanf(" %d", &ans); 


if (ans == 2) 

{ 

goto BEGIN; 

} 

} 

else 

{ 

xs=0; 

ys=0; 

ho=l; 

} 

printf("\nPress Spaceball Button 1 to add a window\n"); 
printf("\nPress Spaceball Button 2 to add another windowVn"); 
printf("\nPress Spaceball Button 3 to delete second window addedVn"); 
printf("\nPress Spaceball Button 4 to delete first window added\n"); 
printf("\nPress Spaceball Button 5 to move tank\n"); 
printf("\nPress Spaceball Button 8 to end simulationVn"); 

/* Array containing target location, this is used to simulate a moving target */ 
locate[l][l]=2; 
locate[l][2]=46; 
locate[2][l]=7; 
locate[2][2]=46; 
locate[3][l]=12; 
locate[3][2]=46; 
locate [4] [1]= 17; 
locate[4][2]=46; 
locate[5][l]=22; 
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locate[5][2]=46; 

locate[6][l]=26; 

locate[6][2]=44; 

locate[7][l]=30; 

locate[7][2]=41; 

locate[8][l]=33; 

locate[8][2]=37; 

locate[9][l]=33; 

locate[9][2]=32; 

locate[10][l]=33; 

locate[10][2]=27; 

locate[ll][l]=33; 

locate[ll][2]=22; 

/* Calls function terrainO */ 
terrainO; 


return; 

} 


^3|c:lc3|c3ie]|c:|c:|e:|c3|c:ie:|c:|c3fc:ic9|e]|(:ie:lct)|e:|e3|t:|c3|c3|e:|c3ic:|e3|c3ic / 


/* This function is WorldToolKit */ 
terrainO 


{ 

void my_actionsO; 


/* Creates new universe *! 

WTuniverse_new(WTDISPLAY_DEFAULT,WTWINDOW_DEFAULT); 
/* Creates flat terrain *! 

terrobj=WTterrain_flat(0.0,35,50,0,0,1.0,1.0,0x0f0,0x0e0,1.0); 


I* Defines pose of lights, and create light object */ 
at[0]=25;at[l]=-35.0;at[2]=-5.0; 
dir[0]=l .0;dir[l]=l .0;dir[2]=l .0; 
niylight=WTlight_new(at,dir, 1.0); 


/* Creates the object spaceball */ 

spaceball=WTspaceballne w(COM 1); 

/* Calls function treeQ to get tree information */ 
tree(); 
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/* Creates small building, sensor, and target, and places them on the terrain. Texture 
from "build2.rgb'’ file is applied to the building */ 
bldg=WTobject_newblock(3,-8,3, 1 , 1 ); 
dpi [X]=29;dpl [Y]=-4;dpl [Z]=29; 

WTobject_translate(bldg,dp 1, WTFRAME_WORLD); 
WTobject_settexture(bldg,"build2.rgb",FALSE,FALSE); 
sensor=WTobject_newblock(.5,.5,.5, 1 , 1 ); 
dp2pC]=0.0;dp2[Y]=-.250;dp2[Z]=0.0; 

WT obj ect_setposition(sensor,dp2); 

WTobject_changecolor(sensor,Oxfff,OxfOf); 

/* Loads target from external Autodesk dxf file */ 

tank=WTobject_new("tank.dxf',&modelview,0.015,FALSE,FALSE); 

WTobject_changecolor(tank,0xfrf,0x777); 

dp3[X]=35.0;dp3[Y]=-1.0;dp3[Z]=0.0; 

rdns=0.0; 

WTobject_setposition(tank,dp3); 
WTobject_rotate(tank,Y,rdns+PI,WTFRAME_WORLD); 
WTobject_setvisibility(tank,FALSE); 

/* Prints to screen title headings */ 

printf("\nxt\tyt\trange\tprcnt\ttotarea"); 

Printf("\n_ \t _ \t _ \t _\t_^\n"); 

/* Sets universe action function to my_actionsQ */ 

WT universe_setactions(my_actions); 

/* Prepares for simulation to start */ 

WT universereadyO; 

/ Scales spaceball sensitivity to the size of the universe */ 

WTsensor_setsensitivity(spaceball, 5.0 *WTumverse getradiusQ): 

/* Connects the viewpoint to the spaceball */ 

WT viewpoint_addsensor(WTuniverse_getviewpoint(),spaceball); 

/* Puts some lights on */ 

WTlight_setcimbient(0.3); 

/* Enters main simulation loop and starts simulation */ 

WT universe_go(); 

/ Deletes universe, simulation loop must be exited to reach this statement */ 

WT uni verse_delete(); 
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} 


return; 


9)c3|c3)^9|cs|c3{c9jc3|cs)c9|c9f(9)(3|c3)c}jc3|c3fc]|c9|c9|c9)c3|c}|c)jcs|c9|c :ic:ie:|c:i(4c:|e%4:9|e9ie9|e3|c3|c:ic:le:|c9|c:|c:)c:ic9|(:|c:ic:ica|c^e^4c^ 

/* This function determines what actions will occur in the universe */ 
void my actionsQ 

{ 

/* Pressing spaceball button ONE adds an additional window */ 

if(WT sensor_getmiscdata(spaceball)&WTSPACEB ALLBUTTON 1) 

{ 

winl=WTwindow_new(l,500,475,375,WTWINDOW_DEFAULT); 

objviewl=WTviewpoint_new(); 

p 1 pC]=xs;p 1 [ Y]=-ho;p 1 [Z]=ys; 

ppl [X]=0.0;ppl [Y]=0.0;ppl [Z]=0.0;ppl [W]=l .0; 

pppl pq=l .0;pppl [Y]=0.0;pppl [Z]=l .3; 

WTviewpoint_setposition(objviewl ,pl); 

WTviewpoint_setorientation(obj viewl ,pp 1); 

WTviewpoint_setdirection(obj viewl ,ppp 1); 

WTwindo w_setviewpoint(win 1 ,obj viewl); 

} 

/* Pressing spaceball button TWO adds a second additional window */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON2) 

{ 

win2=WTwindow_new(505,500,500,375,WTWINDOW_DEFAULT); 

objview2=WTviewpoint_new(); 

p2pC]=33.0;p2[Y]=-10.0;p2[Z]=52.0; 

pp2[X]=0.0;pp2[Y]=0.0;pp2[Z]=0.0;pp2[W]=1.0; 

ppp2pC]=-L0;ppp2[Y]=1.0;ppp2[Z]=-1.2; 

WTviewpoint_setposition(objview2,p2); 

WTviewpoint_setorientation(objview2,pp2); 

WTviewpoint_setdirection(objview2,ppp2); 

WTwindow_setviewpoint(win2,objview2); 

} 
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/* Pressing spaceball button THREE deletes first window added */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON3) 

{ 

WT window_delete(win2); 

} 

/* Pressing spaceball button FOUR deletes second window added */ 

if(WTsensor_getmiscdata(spacebalI)&WTSPACEBALL_BUTTON4) 

{ 

WT windo w_delete( win 1); 

} 

/* Pressing spaceball button FIVE makes tank move to next position */ 

if( WT sensor_getmiscdata(spaceball)&WTSP ACEB ALLBUTTONS) 

{ 

/* Calls function tgtxtytQ to get position information */ 
tgtxtytO; 


pt[X] = xt;pt[Y] = -.75;pt[Z] = yt; 

/* Logical section to determine when to rotate tank based on position */ 
if (yt = 46) 

{ 

rdns = 0.0; 

} 

else if (yt == 44) 

{ 

yrotate =15; 

rdns = y rotate * PI / 180; 
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} 


else if (yt = 41) 

{ 

y_rotate = 25; 

rdns = y_rotate * PI / 180; 

} 

else if (yt = 37) 

{ 

y_rotate = 20; 

rdns = y rotate * PI / 180; 

} 

else if (yt = 32) 

{ 

y_rotate = 5; 

rdns = y_rotate * PI / 180; 

} 

else if (yt =27) 

{ 

y_rotate = 0; 

rdns = y rotate * PI / 180; 

} 

else if (yt =22) 

{ 

yrotate = 0; 

rdns = y_rotate * PI / 180; 
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} 

/* Creates a tank from external Autodesk dxf file, changes it’s color, positions it based 
on the position data, and rotates it if required */ 

WT obj ect_add(tank); 

WTobj ect_setvisibility(tank,TRUE); 

WT obj ect_setposition(tank,pt); 

WTobject_rotate(tank,Y,rdns,WTFRAME_WORLD); 

/* Calls Ios() to determine lines of sight to target faces and other calculations */ 
losQ; 

/* Calls function datatgtQ to display target data */ 
datatgtQ; 

/* Zeros out total area and percent data */ 
totarea=0; 
prcnt=0.0; 

} 

/* Pressing spaceball button EIGHT terminates simulation */ 

if( WTsensor_getmiscdata(spaceball)&WTSP ACEB ALL_BUTTON8) 

{ 

WT uni verse_stop(); 

} 

return; 

} 

tgtXtytQ *♦********♦******♦****»'**♦*****/ 

/* This function determines the value of xt and yt from array locate[ ][ ] */ 
tgtxtytO 

{ 

c=c+l; 

xt=locate[c][l]; 

yt=locate[c][2]; 

return; 

} 
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/* This function calculates LOS data */ 
losQ 


{ 

/* Begins loop inputting targets moving locations */ 
cxt=xt; 
cyt=yt; 

range=sqrt((float)pow((xt-xs),2)+(float)pow((yt-ys),2)); 

/* Calls the function aspectQ to determine how much of the target is presented for 
possible LOS. Vistgt[ ][ ] is the array returned holding the grid location and 
information on the faces of the target which may be seen, n = the number of 
possible detections and is used for looping the algorithm */ 
aspectQ; 

/* Loops to check possible LOS for all surfaees presented by target */ 
r=0; 


for (j=i; j<=n; j++) 


{ 

/* Zeros atten for each run and gets target grid & height data for stepping LOS */ 
atten=0; 
attenf=0; 
xt=vistgt[j][l]; 
yt=vistgt[j][2]; 
ht=vistgt[j][3]; 

/* Calculates target and observer heights. First ground height must be foimd by 
subtracting vegetation height from absolute height. Then sensor and target heights 
above ground are added to obtain absolute elevations of sensor and target */ 
zs=ele v[xs* 5 0+ys] - vgh[xs* 5 0+y s]; 
zt=elev[xt* 5 0+yt] - vgh[xt* 50+yt]; 
zs=zs+ho; 
zt=zt+ht; 


/* Determines difference btwn x & y coordinates, and converts from integer to real */ 
rdx=(xt-xs); 
rdy=(yt-ys); 
idx=rdx; 
idy=rdy; 
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/* If idy > idx skip to stepping in y direction, else proceed stepping in x direction */ 
if (idy >= idx) 

{ 

goto YSTEP; 

} 

else 

{ 

y=ys; 

dy=(yt-ys)/rdx; 

z=zs; 

dz=(zt-zs)/rdx; 

/* This if-else statement ensures moving from sensor to target. Move only from 
sensor because dist from sensor will affect attenuation level of any obstructions */ 
if (xt > xs) 

{ 

/* Apply slope to each step to determine grid passing thru and LOS height in that grid 
compare height to ground height, no LOS exists if ground height > LOS height: 
z = height of LOS 

ztree = height of vegetation 

zdirt = height of the ground */ 

istart=xs+l; 
istop=xt; 
ystart=y; 

for (ix=istart; ix<=istop; ix-H-) 

{ 

y=y+dy; 

z=z+dz; 

nintyO; 

ztree=elev[ix*50+iy]; 
zdirt=ztree-vgh[ix* 50+iy]; 

/* Calculate dist from sensor to grid where LOS currently in heading toward target */ 
dist=sqrt((float)pow((istart-ix),2)+(float)pow((ystart-iy),2)); 


70 


/* Calls function compareQ *! 
compareO; 

if (noios != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

else 

{ 


istart=xs-l; 

istop=xt; 

ystart=y; 


for (ix=istart; ix<=istop; ix—) 


{ 

y=y+dy; 

2 r=z+dz; 

nintyO; 

ztree=elev[ix* 50+iy]; 
zdirt=ztree-vgh[ix* 50+iy]; 

dist=sqrt((float)pow((istart-ix),2)+(float)pow((ystart-iy),2)); 

/* Calls function compareQ */ 
compareQ; 

if (noios != 0) 

{ 

goto FINISH; 

} 
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} 


goto CONTINUE; 

} 

} 

/* This section is used if stepping in y direction and same as stepping in x direction */ 
YSTEP: 

x=xs; 

dx=(xt-xs)/rdy; 

z=zs; 

dz=(zt-zs)/rdy; 
if (yt > ys) 

{ 

istait=ys+l; 

istop=yt; 

xstart=x; 

for (iy=istart; iy<=istop; iy++) 

{ 

x=x+dx; 

z=z+dz; 

nintx(); 

ztree=elev[ix* 50+iy]; 
zdirt=ztree-vgh[ix* 50+iy]; 

dist=sqrt((float)pow((xstart-ix),2)+(float)pow((istart-iy),2)); 

I* Calls function compareQ */ 
compareO; 

if (nolos != 0) 

{ 

goto FINISH; 
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} 

} 


goto CONTINUE; 

} 

else 

{ 


istart=ys-l; 

istop=yt; 

xstart=x; 

for (iy=istart; iy<=istop; iy—) 


{ 

x=x+dx; 

z=z+dz; 

nintxQ; 

ztree=elev[ix* 50+iy]; 
zdirt=ztree-vgh[ix* 5 0+iy]; 

dist=sqrt((float)pow((xstart-ix),2)+(float)pow((istart-iy),2)); 

/* Calls function compareQ */ 
compareQ; 

if (nolos != 0) 

{ 

goto FINISH; 

} ■ 

} 

goto CONTINUE; 

} 

CONTINUE: 
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/* At this point LOS has atten = 0 or a number. Apply this attenuation factor to proj 
area of target to reduce area of visibility. Proj area is determined based on surface 
direction of face in question. This value is 1 for a vertical surface and 2 for a 
horizontal surface. This value is stored in vistgt[ ][ ] array which describes target */ 
if (vistgt[j][4] = 0) 

{ 

aproj=rdy/sqrt(pow(rdy,2)+pow(rdx,2)); 

} 

else 

{ 

aproj=rdx/sqrt(pow(rdy,2)+pow(rdx,2)); 

} 

/* Sees if there is any attenuation to be applied, if so apply it */ 
if (atten = 0) 

{ 

visaproj=aproj; 

} 

else 

{ 

visaproj=( 1 -atten)*aproj; 

} 

/* Sums total visible area presented by target */ 
totarea=totarea+visaproj; 

/* Zeros aproj and visaproj for next LOS */ 
aproj=0; 
visaproj=0; 
r=r+l; 

FINISH: 

nolos=0; 


74 


} 


return; 

} 

aspectQ ******************************/ 

/* This subroutine assigns target grid locations based on central input location. It then 
uses sensor and target locations to determine which faces of target are ideally visible 
to sensor. Faces which are visible have there information stored in array vistgt[ ][ ] 
for return to main program. The number of faces ideally visible are also returned. 
Assign target data to array tgt[ ][ ] based on center grid of target 3x3 each 
exterior vertical face of target is represented */ 
aspectO 

{ 


tgt[l][l]=xt-l; 

tgt[l][2]=yt-2; 

tgt[l][4]=0; 

tgt[2][l]=xt-2; 

tgt[2][2]=yt-l; 

tgt[2][4]=l; 

tgt[3][l]=xt-2; 

tgt[3][2]=yt; 

tgt[3][4]=l; 

tgt[4][l]=xt-2; 

tgt[4][2]=yt+l; 

tgt[4][4]=l; 

tgt[5][l]=xt-l; 

tgt[5][2]=yt+2; 

tgt[5][4]=0; 

tgt[6][l]=xt; 

tgt[6][2]=yt+2; 

tgt[6][4]=0; 

tgt[7][l]=xt+l; 

tgt[7][2]=yt+2; 

tgt[7][4]=0; 

tgt[8][l]=xt+2; 

tgt[8][2]=yt+l; 

tgt[8][4]=l; 

tgt[9][l]=xt+2; 

tgt[9][2]=yt; 

tgt[9][4]=l; 

tgt[10][l]=xt+2; 
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tgt[10][2]=yt-l; 

tgt[10][4]=l; 

tgt[ll][l]=xt+l; 

tgt[ll][2]=yt-2; 

tgt[ll][4]=0; 

tgt[12][l]=xt; 

tgt[12][2]=yt-2; 

tgt[12][4]=0; 

tgt[13][l]=xt; 

tgt[13][2]=yt-l; 

tgt[13][4]=0; 

tgt[14][l]=xt-l; 

tgt[14][2]=yt; 

tgt[14][4M; 

tgt[15][l]=xt; 

tgt[15][2]=yt+l; 

tgt[15][4]=0; 

tgt[16][l]=xt+l; 

tgt[16][2]=yt; 

tgt[16][4]=l; 

/* Assigns target heights, in tgt[ ][ ] */ 
for (j=l; j<=12; j++) 

{ 

tgtD][3]=l; 

} 

for (j“13; j<==16; j-H-) 

{ 

tgt[j][3]=2; 

} 

/* Establishes bounds of the target */ 
xmax=xt+l; 
xniin=xt-l; 
ymax=yt+l; 
ymin=yt-l; 
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/* Determines visible sectors of target */ 

if ((xs <= xmax) && (xs >= xmin)) 

{ 

if (ys > ymax) 

{ 

/* Sensor is directly above target grids, upper faces */ 
for 0=1; j<=4; j-H-) 


{ 

vistgt[l]0]=tgt[5][j]; 

vistgt[2]0]=tgt[6][j]; 

vistgt[3][j]=tgt[7]D]; 

vistgt[4][j]=tgt[15]0]; 

n=4; 

/* Allows for skewed view of a top block side */ 
if (xs < xt) 

{ 

vistgt[5][j]=tgt[14]0]; 

n=5; 

} 

if (xs > xt) 

{ 

vistgt[5]0]=tgt[i6]D]; 

n=5; 

} 

} 

goto END; 

} 
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else 

{ 

/* If the sensor is vertically in line with target grids and it is not above target it must 
be below it, therefore it sees lower faces */ 
for (j=l; j<=4; j-H-) 

{ 

vistgt[l](j]=tgt[l][j]; 

vistgt[2]D]=tgt[12]D]; 

vistgt[3][j]=tgt[ll][j]; 

vistgt[4]0]=tgt[13]0]; 

n=4; 

/* Allows for skewed view of a top block side */ 
if (xs < xt) 

{ 

vistgt[5][j]=tgt[14]0]; 

n=5; 

} 

if (xs > xt) 

{ 

vistgt[5]0]=tgt[16][j]; 

n=5; 

} 

} 

goto END; 

} 

} 

if (xs < xmin) 
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{ 


if ((ys >= ymin) && (ys <= ymax)) 

{ 

/* Sensor is horizontally aligned with target grids and to left of target, therefore it sees 
left side faces */ 

for G=l; j<=4; j++) 


{ 

vistgt[l][j]=tgt[2]D]; 

vistgt[2]Ij]=tgt[3][j]; 

vistgt[3][j]=tgt[4][j]; 

vistgt[4][j]=tgt[14][j]; 

n=4; 

/* Allows for skewed view of top block side */ 
if (ys < yt) 

{ 

vistgt[5][j]=tgt[13][j]; 

n=5; 

} 

if (ys > yt) 

{ 

vistgt[5]D]=tgt[15]D]; 

n=5; 

} 

} 

goto END; 


} 

if (ys < ymin) 
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{ 


/* Sensor is to left and below target, all of left side and lower faces seen */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l][j]=tgt[l][j]; 

vistgt[ 2 ][j]=tgt[ 2 ][j]; 

vistgt[3][j]=tgt[3][j]; 

vistgt[4][j]=tgt[4][j]; 

vistgt[5]|j]=tgt[12][j]; 

vistgt[6]|j]=tgt[ll][j]; 

vistgt[7]|j]=tgt[13][j]; 

vistgt[8][j]=tgt[14][j]; 

n=8; 

} 

goto END; 

} 

if (ys > ymax) 

{ 

/* Sensor is to left side and above target, all of left side and upper faces seen */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l]|j]=tgt[2][j]; 

vistgt[2]|j]=tgt[3]|j]; 

vistgt[3]0]=tgt[4][j]; 

vistgt[4][j]=tgt[5]Ij]; 

vistgt[5][j]=tgt[5]D]; 

vistgt[6][j]=tgt[7][j]; 

vistgt[7]|j]=tgt[14][j]; 

vistgt[8]D]=tgt[15]|j]; 

n=8; 

} 
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goto END; 


} 

} 

/* Sensor is right of target */ 

if ((ys >= ymin) && (ys <= ymax)) 

{ 

/* Sensor horizontally aligned w/target and right of target, therefore right faces seen */ 
for (j=l; j<=4; j-H-) 


{ 

vistgt[l][j]=tgt[8][j]; 

vistgt[2][j]=tgt[9]D]; 

vistgt[3][j]=tgt[10][j]; 

vistgt[4]|j]=tgt[16]lj]; 

n=4; 

/* Allows a skewed view of a top side */ 
if (ys < yt) 

{ 

vistgt[5]D]=tgt[13][j]; 

n=5; 

} 

if (ys > yt) 

{ 

vistgt[5][j]=tgt[15][j]; 

n=5; 

} 

} 

goto END; 
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} 

if (ys < ymin) 

{ 

/* Sensor is right of and below target, all right and lower faees seen */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l][j]=tgt[8][j]; 

vistgt[2]|j]=tgt[9]D]; 

vistgt[3][j]=tgt[10]|j]; 

vistgt[4][j]=tgt[l][j]; 

vistgt[5][j]-tgt[12][j]; 

vistgt[6][j]=tgt[ll][j]; 

vistgt[7][j]=tgt[13]0]; 

vistgt[ 8 ][j]=tgt[ 16 ]D]; 

n=8; 

} 

goto END; 

} 

if (ys > ymax) 

{ 

/* Sensor is right and above target, all right and upper faces seen */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l][j]=tgt[8][j]; 

vistgt[2][j]=tgt[9]lj]; 

vistgt[3]|j]=tgt[10][j]; 

vistgt[4][j]=tgt[5]Ij]; 

vistgt[5][j]=tgt[6][j]; 

vistgt[6][j]=tgt[7][j]; 

vistgt[7]|j]=tgt[16]Ij]; 

vistgt[8][j]=tgt[15][j]; 

n=8; 
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} 

goto END; 

} 


END: 

return; 

} 

nintxQ ******************♦************/ 
/* This function round up or down to the nearest integer for ix */ 
nintxQ 

{ 

ix=floor(x); 

zx=fabs(x-ix); 

if (zx >= .5) 

{ 

ix=ceil(x); 

} 

else 

{ 

ix=floor(x); 

} 


return; 

} 

^3|(3|c3|c3]c:|c:|e3)e:|cs|::|c9|ca|ej|c%3te9fe:(c9|e:)::|c:|e3|e;lc:|ej|c>|c:|e]|e:(c)|e:|c IlilltyQ ****************************♦**/ 

/* This function round up or down to the nearest integer for iy */ 
nintyO 

{ 

iy=floor(y); 

zy=fabs(y-iy); 
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if (zy >= .5) 

{ 

iy=ceil(y); 

} 

else 

{ 

iy=floor(y); 

} 


return; 

} 


/♦***************************** compareO *********************♦**♦*♦■.■*/ 
/* This function compares LOS data to terrain data to see if LOS is obstructed */ 
compareO 

{ 

/* Compares LOS height to ground height */ 
if (z < zdirt) 

{ 

nolos=l; 

} 

else if (z < ztree) 

{ 

/* The following determine attenuation due to vegetation. If feature is 200 m away 
then appears as solid object, distance arbitrarily selected. Checks UCl if object has 
height but no UCI assume to be trunk of object/man made structure, LOS blocked */ 
if (uci[ix*50+iy] = 0) 

{ 

nolos=2; 
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} 


else if (z > uci[ix*50+iy]) 

{ 

/* Checks nature bit, structures block LOS. Manmade objects have a nature bit of 0 */ 
if (nat[ix*50+iy] = 0) 

{ 

nolos=3; 

} 

/* If program passes above test then obstruction is vegetation and any other parts of 
tree will be assumed as foliage. Current assumption is foliage of 1 meter thickness 
has an attenuation of 30%. This value is modified as function of distance xmtil 
modified value reaches an attenuation of 100% at terminal distance, 200 meters. At 
200 meters all objects appear solid. It is assumed the modification factor is linear */ 
if(dist>200) 

{ 

nolos=4; 

} 

else 

{ 

attenf=denfol*( 1 +2.33 *dist/200); 

} 

} 

/* Allows for sensor hiding behind or in foliage to see through w/out attenuation *! 
if (dist <= 1) 

{ 

attenf=0; 

} 
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/* Sums attenuations */ 

atten=atten+attenf; 

/* If total attenuation exceeds 95%, LOS is blocked */ 
if (atten > .95) 

{ 

nolos=5; 

} 

} 


return; 

} 


/****************^:^^^^^:^^^^^,^^ datatgto ******************************/ 

/* This function displays to screen: range, % of target faces visible, and total area of 
target faces visible */ 

datatgto 

{ 

prcnt=floor((r / n)*100); 

printf("\n%d\t%d\t%3.2At%d\t%3.2f\n",cxt,cyt,range,prcnt,totarea); 

return; 

} 


/*****************^*^,:^^^^^^^^^^,^: ***♦****♦*♦*♦♦♦*♦*♦*♦♦♦*♦*♦*♦♦*/ 

/* This function creates trees & places them on terrain from info in "tree dat" */ 
static void tree() 

{ 


/* Declare variables */ 
int row; 
float rad,x,z; 

/* Opens file "tree.dat" and reads dimensional data */ 
fp 1 =fopen("tree.dat","r"); 
for (row=0; row<7; row-H-) 

{ 
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fscanf(fpl," %f %f %f\n",&mdata[row][0],&mdata[row][l],&mdata[row][2]); 

/* Defines variables rad, x, z */ 

rad=mdata[row] [0] ;x=mdata[row] [ 1 ] ;z=mdata[ro w] [2]; 

/* Defines cube as new sphere and cyl as a new cylinder attaches them together. 
Texture from "grass.rgb" and "wood.rgb" is applied to the tree trunk and leaves *! 
factorspC]=factors[Z]=.50;factors[Y]=1.25; 
sphere = WTobject_newsphere(rad,5,5,l,l,l); 
WTobject_stretch(sphere,factors,p,WTFRAME_WORLD); 

cyl = WTobject_newcylinder(rad/1.25,rad/5,4,l,l»l); 
dp4pC]=0;dp4[Y]=-(1.3*rad);dp4[Z]=0; 
WTobject_translate(sphere,dp4,WTFRAME_WORLD); 
WTobject_attach(sphere,cyl); 

WTobject_add(sphere); 
dp5[X]=x;dp5[Y]=-rad/4;dp5[Z]=z; 
\VTobject_translate(sphere,dp5,WTFRAME_WORLD); 
WTobject_settexture(sphere,"grass.rgb",FALSE,FALSE); 
WTobject_settexture(cyl,"wood.rgb",FALSE,FALSE); 

} 

fclose(Q)l); 

return; 
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APPENDIX I. PROGRAM PROG2.C 


/♦ PROGRAM PROG2.C */ 


^****l(!*****:(c*j|ei(c***i)c%j|c**iC**:|cl|ci|ci|c********l|!********)|ci(c**i|ci|c*****i|c:|c*****i|c****)|c^ 


/* This program calculates Line Of Sight (LOS) data and visualizes a target moving*/ 
/* through a 35x50 grid using a database of Pegasus numbers and is designed to */ 

/* incorporate attenuation by vegetation. The main section of this program calls */ 

/* function terrainQ which is used to start WorldToolKit and create a universe */ 

/* where there is a flat terrain with trees and a building located on it. The trees and*/ 
/* building are represented as close approximations to real objects. The simulation */ 
/* has the target moving along a path behind the trees and buildings. Function */ 
/* terrainQ calls function losQ which is used to calculate target data. */ 


% 9|c j|c 3|c 3ie 4; % 9ic % 9|c :|c 9le sfc % % )|e}|e :ic 9|c 3|c :|e 3fe 3|c 3|c :|c % % 3ic j|e :)c 9)( )|c :1c % i)e :ie j|c He 3|e :|e 3|c :|c 9|c sic 3fc3lc :|c 3|e sfe % :|c :fc jfc 3l( :ic :fc 3|e ){cy 


/* Standard C and WorldToolKit header files */ 
#include <stdio.h> 

#include <math.h> 

#include"wt.h" 

#include"wt.p" 


/* Defines a pointer spaceball to structure type WTsensor */ 
static WTsensor *spaceball=NULL; 
static WTsensor *mouse=NULL; 

/* Calls function treeQ */ 
static void treeQ; 


/* Defines windows, viewpoints, nodes, and paths */ 

static WTwindow *winl, *win2, *win3; 

static WTviewpoint *objviewl, *objview2, *obJview3; 

/* Defines objects */ 

WTobject *bldg, *copy, *cyl, *original, *sensor, *sphere, *tank, *terrobj; 
WTobject *nodeobj; 


/* Defines path */ 
static WTpath *tnkpth; 

/* Defines pointers to WTp3, WTq, and WTpq structures */ 
WTp3 at,dpl,dp2,dp3,dp4,dp5,dir,factors,p,pl,p2,pppl,ppp2,pp,pt; 
WTq ppl,pp2; 

WTpq model view; 


/* Defines light object to be a pointer to type WTlight */ 
WTlight *mylight; 
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/* Initialize arrays and declares variables */ 

int ans,c,cxt,cyt,ho,ht,i,ix,iy,idx,idy,istart,istop,j,n,nmbr,nolos,prcnt,win,wdow,xs,xt; 
int xmax,xmin,xstart,ys,yt,yniax,ymin,ystart,zs,zt,zdirt,ztree,binelev[ 1750],binnat[ 1750]; 
int binuci[l750],binvghindex[ 1750],binvid[ 1750],elev[ 1750],nat[ 1750],realvgh[ 10]; 
inttgt[17][5],tile[1750]uci[1750],vgh[1750],vid[1750],vghindex[1750],vistgt[9][9]; 

float aproj,atten,attenf,dx,dy,dz,denfol,dist,r,rad,rdx,rdy,row,rdns,range; 

float totarea,visaproj ,x,y,y_rotate,z,zx,z,mdata[7] [3]; 

/* Standard C file pointers */ 

FILE *fp; 

FILE *fpl; 

main() 

{ 

/* Reads database information into array from data file "btlfld_terr.dat" */ 
fp=fopen("btlfld_terr.daf',"r"); 
for (i=0; i<=1749; i-H-) 


{ 

fscanf(fip," %d", &tile[i]); 

} 

fclose(fp); 

/* Assigns 1 meter of foliage an attenuation of 30% of the LOS */ 
denfol=0.3; 

/* The vegetation height from pegasus has values of 0-15, each of these values 

represents a particular height or range of heights. The following is used to correlate 
the vgh value to a meaningful height */ 
realvgh[0]=0; 
realvgh[l]=0; 
realvgh[2]=l; 
realvgh[3]=2; 
realvgh[4]=3; 
realvgh[5]=4; 
realvgh[6]=5; 
realvgh[7]=8; 
realvgh[8]=10; 
realvgh[9]=15; 
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realvgh[10]=20; 

realvgh[ll]=25; 

realvgh[12]=30; 

realvgh[13]=35; 

realvgh[14]=40; 

realvgh[15]=47; 

/* Once the database for the grid desired has been read into an array, the components 
of information are extracted from the 32 bit number using the AND and SHIFT 
functions. The groups of information of use in the program are placed in their own 
arrays for rapid recall during calculations as follows: 


elevation of highest point in grid - ELEV 

under cover index - UCI 

converted vegetation height - VGH 

vegetation ID - VID 

nature bit - NAT */ 


for (i=0; i<=1749; i-H-) 


{ 

binuci[i]=tile[i] & 786432; 
binvghindex[i]=tile[i] & 15360; 
binvid[i]=tile[i] & 768; 
binnat[i]=tile[i] & 128; 
binelev[i]=tile[i] & 4292870144; 
uci[i] = binuci[i] » 18; 
vghindex[i] = binvghindexp] » 10; 
vgh[i]=realvgh[vghindex[i]]; 
vid[i] = binvid[i] » 8; 
nat[i] = binnat[i] » 7; 
elev[i] = binelev[i] » 21; 

} 

/* This program is currently written to run in a stand alone mode. Sensor information 
has a default value, but can be changed by answering prompts from the keyboard. 
Accepts default values or input sensor location and height */ 
printf("\nThe Default Sensor Coordinates are xs = 0, zs = 0"); 
printf("\nand hs = l\n"); 

printf("\nDo you wish to Change these values? l=Yes, 2=No\n"); 
scanf(" %d",&ans); 

if (ans = 1) 
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{ 

BEGIN: 

printf("\nEnter Sensor X Coordinate pC,Y)\n"); 
scanf("%d,%d",&xs,&ys); 
printf("\nEnter Sensor Height\n"); 
scanf("%d",&ho); 

printf("\nAre You Sure? l=Yes 2=No \n"); 
scanf(" %d", &ans); 


if (ans = 2) 

{ 

goto BEGIN; 

} 

} 

else 

{ 

xs=0; 

ys=0; 

ho=l; 

} 

printf("\nPress Spaceball Button 1 to add a window\n"); 
printf("\nPress Spaceball Button 2 to add another window\n"); 
printf("\nPress Spaceball Button 3 to delete first window added\n"); 
printf("\nPress Spaceball Button 4 to delete second window addedVn"); 
printf("\nPress Spaceball Button 5 to start tank motion\n"); 
printf("\nPress Spaceball Button 6 to replay simulation\n"); 
printf("\nPress Spaceball Button 8 to end simulation\n"); 

/* Calls function terrainQ */ 
terrainO; 

return; 

} 
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^jie+*:!€♦♦*♦♦♦♦*♦♦***********♦**** tcrrainQ ******************************/ 

/* This function is WorldToolKit */ 

terrainO 

{ 

void my_actions(); 

/* Creates new universe */ 

WTuniverse_new(WTDISPL AY_DEF AULT,WTWINDOW_DEF AULT); 

/* Creates the object terrobj */ 

terrobj=WTterrain_flat(0.0,35,50,0,0,1.0,1.0,0x0fD,0x0e0,1.0); 

/* Defines pose of lights, and create light object */ 
at[0]=25;at[l]=-35.0;at[2]=-5.0; 
dir[0]=l .0;dir[l]=l .0;dir[2]=l .0; 
mylight=WTlight_new(at,dir, 1.0); 

/* Creates the object spaceball or mouse */ 
spaceball=WT spaceball_new(COM 1); 

/* Calls function treeQ to get tree information */ 
treeQ; 

/* Creates small building, sensor, and target, and places them on the terrain */ 
bldg=WTobject_newblock(3,-8,3,1,1); 
dpi pC]=29;dpl [Y]=-4;dpl [Z]=29; 

WT obj ect_translate(bldg,dp 1, WTFRAME_W ORLD); 
sensor=WTobject_newblock(.5,.5,.5,1,1); 
dp2[X]=0.0;dp2[Y]=-.250;dp2[Z]=0.0; 

■\^object_setposition(sensor,dp2); 

WTobject_changecolor(sensor,0jrfff,0xf0f); 

/* Loads tank from external Autodesk dxf file */ 

tank=WTobject_new("tankl 80.dxf’,&modelview,0.015,FALSE,FALSE); 

WTobject_changecolor(tank,0xfFf,0x777); 

dp3pC]=15.0;dp3[Y]=5.0;dp3[Z]=25.0; 

rdns=0.0; 

WT obj ect_setposition(tank,dp3); 

WT obj ect_rotate(tank, Y,rdns+PI, WTFRAME_W ORLD); 

/* Tank path is loaded from external file */ 

nodeobj=WTobject_newblock(. 1,. 1,. 1,1,1); 
tnkpth=WTpath_load("tank.pth",nodeobj); 


/* Prints to screen title headings */ 

printf("\nxt\tyt\trange\tprcnt\ttotarea"); 

printf("\n_\t_\t_\t_\t_\n"); 

/* Sets universe action function to my_actionsO 
WTuniverse_setactions(my_actions); 

/* Prepares for simulation to start */ 

WT uni verse_ready 0; 

/* Scales spaceball or mouse sensitivity to the size of the universe */ 

WTsensor_setsensitivity(spaceball, 5.0 *WTuniverse_getradius()); 

/* Connects the viewpoint to the spaceball or mouse */ 

WTviewpoint_addsensor(WTuniverse_getviewpoint(),spaceball); 

/* Puts some lights on */ 

WTlight_setambient(0. 3 ); 

/* Enters main simulation loop and starts simulation */ 

WTuniverse_go(); 

/* Deletes universe, simulation loop must be exited to reach this statement */ 

WT uni verse_delete(); 

return; 

} 

Z********************^**,,*^,, my_actionsO ****************♦********♦**/ 

/* This function determines what actions \vill occur in the universe */ 
void my_actions() 

{ 

/* Pressing spaceball button ONE adds an additional \vindow */ 

if(WTsensor_getmiscdata(spaceball)«feWTSPACEBALL_BUTTON 1) 

{ 

winl=WTwindow_new(l, 500,475,375, WTWINDOW_DEF AULT); 

objviewl=WTviewpoint_new(); 

pi [X]=xs;pl [Y]=-ho;pl [Z]-ys; 

ppl pC]=0.0;ppl [Y]=0.0;ppl [Z]=0.0;ppl [W]=l .0; 

ppp 1 [X]=1.0;ppp 1 [Y]=0.0;ppp 1 [Z]=1.3; 
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WTviewpoint_setposition(obj viewl ,p 1); 
WTviewpoint_setorientation(obj viewl ,pp 1); 
WTviewpoint_setdirection(obj viewl ,ppp 1); 
WTwindow_setviewpoint(winl ,obj viewl); 

} 

/* Pressing spaceball button TWO adds a second additional window */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON2) 

{ 

win2=WTwindow_new(505,500,500,375,WTWINDOW_DEFAULT); 
obj view2=WT viewpoint_new(); 
p2[X]=33.0;p2[Y]=-10.0;p2[Z]=52.0; 
pp2pC]=0.0;pp2[Y]=0.0;pp2[Z]=0.0;pp2[W]=1.0; 
ppp2pC]=-1.0;ppp2[Y]=1.0;ppp2[Z]=-1.2; 
WTviewpoint_setposition(objview2,p2); 
WTviewpoint_setorientation(objview2,pp2); 
WTviewpoint_setdirection(objview2,ppp2); 
WTwindow_setviewpoint(win2,objview2); 

} 

/* Pressing spaceball button THREE deletes first window added */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON3) 

{ 

WTwindow_delete(win2); 

} 

/* Pressing spaceball button FOUR deletes second window added */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON4) 

{ 

WTwindow_delete(winl); 

} 

/* Pressing spaceball button FIVE starts tank motion along path */ 

if(WT sensor_getmiscdata(spaceball)& WTSP ACEB ALLBUTT ON5) 
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{ 

WTpath_setobject(tnkpth,tank); 

WTpath_play(tnkpth); 

WTpath_record(tnkpth); 

} 

/* Pressing spaceball button SIX restarts tank motion */ 

if(WTsensor_getmiscdata(spacebalI)&WTSPACEBALL_BUTTON6) 

{ 

WTpath_stop(tnkpth); 

WTpath_rewind(tnkpth); 

WTpath_play(tnkpth); 

} 

/* Based on tank position, function tgtposnQ called */ 
WTobject_getposition(tank,pp); 

if(ppPC] = 2) 

{ 

tgtposnO; 

} 

if(ppPC] = 7) 

{ 

tgtposnQ; 

} 

if (ppra = 12) 

{ 

tgtposnQ; 
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} 


if (pp[X] = 17) 

{ 

tgtposnO; 

} 

if(ppP(]=22) 

{ 

tgtposnO; 

} 

if(ppPC]=26) 

{ 

tgtposnO; 

} 

if(pp[X] = 30) 

{ 

tgtposnO; 

} 

if ((ppPC] = 33) && (pp[Z] = 37)) 

{ 

tgtposnO; 

} 

if ((pp[X] = 33) && (pp[Z] = 32)) 
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{ 

tgtposnO; 

} 

if ((ppPC] = 33) && (pp[Z] = 27)) 

{ 

tgtposnO; 

} 

if ((ppPC] = 33) && (pp[Z] = 22)) 

{ 

tgtposnO; 

} 

/* Pressing spaceball button EIGHT terminates simulation */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON8) 

{ 

WTuniversestopO; 

} 

return; 

} 


/*********:^**^f^,*t*******nf****if tgtposnO ************♦********♦***♦*♦♦*/ 
/* This function calls losQ and datatgtQ, receives value of xt and zt from 
WTobject_getposition, and displays target data to screen */ 
tgtposnO 

{ 


xt=pppC];yt=pp[Z]; 
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/* Calls function los() to determine LOS to target faces and other calculations */ 
losQ; 

/* Calls function datatgtQ to display target data */ 
datatgtO; 

/* Zeros out total area and percent data */ 
totarea=0; 
prcnt=0.0; 

return; 

} 

y:|e:|c:ic9|e3|e:ic:)e:|e4c9i()|caic3)c%]|c3|c:|c3ie:)e3|e3|e:ie3(c4::|e:ic:|c:|c:ie:|e:|c% losQ ********♦***♦♦**♦♦♦♦**♦♦♦♦♦*♦♦♦♦/ 

/* This function calculates LOS data */ 

losQ 

{ 

/* Begins loop inputting targets moving locations */ 
cxt=xt; 
cyt=yt; 

range=sqrt((float)pow((xt-xs),2)+(float)pow((yt-ys),2)); 

/* Calls the function aspectQ to determine how much of the target is presented for 
possible LOS. Vistgt[ ][ ] is the array returned holding the grid location and 
information on the faces of the target which may be seen, n = the number of 
possible detections and is used for looping the algorithm */ 
aspectQ; 

/* Loops to check possible LOS for all surfaces presented by target */ 
r=0; 

for (j=l; j<=n; j-H-) 

{ 

/* Zeros atten for each run and gets target grid height data for stepping LOS */ 
atten=0; 
attenf=0; 
xt=vistgt[j][l]; 
yt=vistgt[j][2]; 
ht=vistgtD][3]; 
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/* Calculates target and observer heights. First ground height must be found by 

subtracting vegetation height from absolute height. Then sensor and target heights 
above ground are added to obtain absolute elevations of sensor and target */ 
zs=elev[xs*50+ys]-vgh[xs*50+ys]; 
zt=elev[xt*50+yt]-vgh[xt*50+yt]; 
zs=zs+ho; 
zt=zt+ht; 


/* Determines difference btwn x & y coordinates and convert from integer real */ 
rdx=(xt-xs); 
rdy=(yt-ys); 
idx=rdx; 
idy=rdy; 

/* If idy > idx skip to stepping in y direction, else proceed in x direction */ 
if (idy >= idx) 

{ 

goto YSTEP; 

} 

else 

{ 


y=ys; 

dy=(yt-ys)/rdx; 

z=zs; 

dz=(zt-zs)/rdx; 

/* This if-else statement ensures moving from sensor to target. Move only from 
sensor because dist from sensor will affect attenuation level of any obstructions */ 
if (xt > xs) 

{ 

/* Apply slope to each step to determine grid passing thru and LOS height in that grid 
compare height to ground height, no LOS will exist if ground height > LOS height; 
z = height of LOS 

ztree = height of vegetation 

zdirt == height of the ground */ 

istart=xs+l; 
istop=xt; 
ystart=y; 
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for (ix=istart; ix<=istop; ix-H-) 


{ 

y=y+dy; 

z=z+dz; 

nintyO; 

ztree=elev[ix*50+iy]; 
zdirt=ztree-vgh[ix*50+iy]; 

/* Calculate dist from sensor to grid where LOS currently in heading toward target */ 
dist=sqrt((float)pow((istart-ix),2)+(float)pow((ystart-iy),2)); 

/* Calls function compareQ */ 
compareQ; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

else 

{ 


istart=xs-l; 

istop=xt; 

ystart=y; 


for (ix=istart; ix<=istop; ix--) 


{ 

y=y+dy; 

z=z+dz; 

nintyO; 

ztree=elev[ix* 50+iy]; 
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zdirt=ztree-vgh[ix*50+iy]; 

dist=sqrt((float)pow((istart-ix), 2 )+(float)pow((ystart-iy), 2 )); 

/* Calls function compareQ */ 
compareO; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

} 

/* This section is used if stepping in y direction and same as stepping in x direction */ 
YSTEP; 

x=xs; 

dx=(xt-xs)/rdy; 

z=zs; 

dz=(zt-zs)/rdy; 
if (yt > ys) 

{ 

istart=ys+l; 

istop=yt; 

xstart=x; 

for (iy=istart; iy<=istop; iy-H-) 

{ 

x=x+dx; 

z=z+dz; 
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nintxQ; 

ztree=elev[ix* 50+iy]; 
zdirt=ztree-vgh[ix*50+iy]; 

dist=sqrt((float)pow((xstart-ix),2)+(float)pow((istart-iy),2)); 

/* Calls function compareQ */ 
compareO; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

else 

{ 


istart=ys-l; 

istop=yt; 

xstart=x; 

for (iy=istart; iy<=istop; iy-) 


{ 

x=x+dx; 

z=z+dz; 

nintxQ; 

ztree=elev[ix* 50+iy]; 
zdirt=ztree-vgh[ix* 50+iy]; 

dist=sqrt((float)pow((xstart-ix),2)+(float)pow((istart-iy),2)); 

/* Calls function compareQ */ 
compareQ; 

if (nolos != 0) 
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{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

CONTINUE: 

/* At this point LOS has atten = 0 or a number. Apply this attenuation factor to proj 
^ea of target to reduce area of visibility. Proj area is determined based on surface 
direction of face in question. This value is 1 for a vertical surface and 2 for a 

horizontal surface. This value is stored in array vistgt[ ][ ] which describes target */ 
if (vistgt[j][4] = 0) 

{ 

aproj=rdy/sqrt(pow(rdy, 2 )+pow(rdx, 2 )); 

} 

else 

{ 

aproj=rdx/sqrt(pow(rdy, 2 )+pow(rdx, 2 )); 

} 

/* Sees if there is any attenuation to be applied, if so apply it */ 
if (atten = 0) 

{ 

visaproj=aproj; 

} 


106 


visaproj=( 1 -atten)*aproj; 

} 

/* Sums total visible area presented by target */ 
totarea=totarea+visaproj; 

/* Zeros aproj and visaproj for next LOS */ 


aproj=0; 

visaproj=0; 

r=r+-l; 

FINISH: 

nolos=0; 

} 

return; 

} 

y3|c3|c3|e)fc3ie3f(9ie]|c:|cj|e9|e:le9|c:|e:|e)|c^:l(t3ie3|c3ic:|c3ic3|ci|c:|c3ie3|ei|c 

/* This subroutine assigns target grid locations based on central input location. It then 
uses sensor and target locations to determine which faces of target are ideally visible 
to sensor. Faces which are visible have there information stored in array vistgt[ ][ ] 
for return to main program. The number of faces ideally visible are also returned. 
Assign target data to array tgt[ ][ ] based on center grid of target 3x3 each exterior 
vertical face of target is represented */ 

aspectQ 

{ 


tgt[l][l]=xt-l; 

tgt[l][2]=yt-2; 

tgt[l][4]=0; 

tgt[2][l]=xt-2; 

tgt[2][2]=yt-l; 

tgt[2][4]=l; 

tgt[3][l]=xt-2; 

tgt[3][2]=yt; 

tgt[3][4]=l; 

tgt[4][l]=xt-2; 

tgt[4][2]=yt+l; 
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tgt[4][4]=l; 

tgt[5][l]=xt-l; 

tgt[5][2]=yt+2; 

tgt[5][4]=0; 

tgt[6][l]=xt; 

tgt[6][2]=yt+2; 

tgt[6][4]=0; 

tgt[7][l]=xt+l; 

tgt[7][2]=yt+2; 

tgt[7][4]=0; 

tgt[8][l]=xt+2; 

tgt[8][2]=yt+l; 

tgt[8][4]=l; 

tgt[9][l]=xt+2; 

tgt[9][2]=yt; 

tgt[9][4]=l; 

tgt[10][l]=xt+2; 

tgt[10][2]=yt-l; 

tgt[10][4]=l; 

tgt[ll][l]=xt+l; 

tgt[ll][2]=yt-2; 

tgt[ll][4]=0; 

tgt[12][l]=xt; 

tgt[12][2]=yt-2; 

tgt[12][4]=0; 

tgt[13][l]=xt; 

tgt[13][2]=yt-l; 

tgt[13][4]=0; 

tgt[14][l]=xt-l; 

tgt[14][2]=yt; 

tgt[14][4]=l; 

tgt[15][l]=xt; 

tgt[15][2]=yt+l; 

tgt[15][4]=0; 

tgt[16][l]=xt+l; 

tgt[16][2]=yt; 

tgt[16][4]=l; 

/* Assigns target heights, in tgt[ ][ ] ♦/ 
for (j=l; j<=12; j-H-) 


{ 

tgtD][3]=l; 
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} 

for (j=13; j<=16; j++) 

{ 

tgt[j][3]=2; 

} 

/* Establishs bounds of the target */ 
xmax=xt+l; 
xmin=xt-l; 
ymax=yt+l; 
ymin=yt-l; 


/* Determine visible sectors of target */ 

if ((xs <= xmax) && (xs >= xmin)) 

{ 

if (ys > ymax) 

{ 

/* Sensor is directly above target grids, upper faces */ 
for (j=l; j<=4; j-H-) 


{ 

vistgt[l]D]=tgt[5]D]; 
vistgt[2][j]=tgt[6][j]; 
vistgt[3][j]=tgt[7]G]; 
vistgt[4]0]=tgt[15][j]; 
n=4; ■ 

/* Allows for skewed view of a top block side */ 
if (xs < xt) 

{ 

vistgt[5][j]=tgt[14]D]; 

n=5; 
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} 


if (xs > xt) 

{ 

vistgt[5][j]=tgt[16]0]; 

n=5; 

} 

} 

goto END; 

} 

else 

{ 

^ sensor is vertically in line with target grids and it is not above target it must 

be below it, therefore it sees lower faces */ 

for (j=l; j<=4; j-H-) 

{ 

vistgt[l]0Hgt[l]0]; 

vistgt[ 2 ]D]-tgt[ 12 ] 0 ]; 

vistgt[3]D]=tgt[ll]0]; 

vistgt[4]0]=tgt[13]0]; 

n=4; 

/* Allows for skewed view of a top block side */ 
if (xs < xt) 

{ 

vistgt[5][j]=tgt[14]0]; 

n=5; 

} 

if (xs > xt) 
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{ 


vistgt[5]D]=tgt[16][j]; 

n=5; 

} 

} 

goto END; 

} 

} 

if (xs < xmin) 

{ 

if ((ys >= ymin) && (ys <= ymax)) 

{ 

/* Sensor is horizontally aligned with target grids and to left of target, therefore it sees 
left side faces */ 

for (j=l; j<=4; j-H-) 


{ 

vistgt[l][j]=tgt[2]D']; 

vistgt[2][j]=tgt[3]D]; 

vistgt[3]D]=tgt[4][j]; 

vistgt[4]|j]=tgt[14][j]; 

n=4; 

/* Allows for skewed view of top block side */ 
if (ys < yt) 

{ 

vistgt[5]G]=tgt[13]G]; 

n=5; 

} 
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if (ys > yt) 

{ 

vistgt[5]D]=tgt[15]D]; 

n=5; 

} 

} 

goto END; 

} 

if (ys < ymin) 

{ 

/ Sensor is to left and below target, all of left side and lower faces seen */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l][j]=tgt[l][j]; 

vistgt[2]|j]=tgt[2][j]; 

vistgt[3][j]=tgt[3]D]; 

vistgt[4][j]=tgt[4]ij]; 

vistgt[5][j]-tgt[12][j]; 

vistgt[6][j]=tgt[ll][j]; 

vistgt[7][j]=tgt[13]|j]; 

vistgt[8][j]=tgt[14][j]; 

n=8; 

} 

goto END; 

} 

if (ys > ymax) 

{ 
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/* Sensor is to left side and above target, all of left side and upper faces seen */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l][j]=tgt[2][j]; 

vistgt[2][j]=tgt[3][j]; 

vistgt[3][j]=tgt[4]G]; 

vistgt[4]D]=tgt[5][j]; 

vistgt[5][j]=tgt[5][j]; 

vistgt[6][j]=tgt[7]|j]; 

vistgt[7][j]=tgt[14][j]; 

vistgt[8][j]=tgt[15][j]; 

n=8; 

} 

goto END; 

} 

} 

/* Sensor is right of target */ 

if ((ys >= ymin) && (ys <= ymax)) 

{ 

/* Sensor horizontally aligned vs^/target and right of target, therefore right faces seen */ 
for 0=1; j<=4; j++) 


{ 

vistgt[l][j]=tgt[8][j]; 

vistgt[2][j]=tgt[9][j]; 

vistgt[3]0]=tgt[10][j]; 

vistgt[4][j]=tgt[16][j]; 

n=4; 

/* Allows a skewed view of a top side */ 
if (ys < yt) 

{ 
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vistgt[5]0]=tgt[I3][j]; 

n=5; 

} 


if (ys > yt) 

{ 

vistgt[5]|j]-tgt[15][j]; 

n=5; 

} 

} 

goto END; 

} 

if (ys < ymin) 

{ 

/* Sensor is right of and below target, all right and lower faces seen */ 
for G=l; j<=4; j++) 

{ 

vistgt[l]|j]=tgt[8][j]; 

vistgt[2]|j]=tgt[9]Ij]; 

vistgt[3]Ij]=tgt[10][j]; 

vistgt[4][j]=tgt[l][j]; 

vistgt[5]|j]=tgt[12]|j]; 

vistgt[6][j]=tgt[l l]|j]; 

vistgt[7]|j]=tgt[13]D]; 

vistgt[8][j]=tgt[16]|j]; 

n=8; 


goto END; 
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if (ys > ymax) 

{ 

/* Sensor is right and above target, all right and upper faces seen */ 
for (j=l; j<=4; j++) 

{ 

vistgt[l][j]=tgt[8]0]; 

vistgt[2]0]=tgt[9][j]; 

vistgt[3]D]=tgt[10]D]; 

vistgt[4]0]=tgt[5]0]; 

vistgt[5]D]=tgt[6]D]; 

vistgt[6]0]=tgt[7][j]; 

vistgt[7]0]=tgt[16]Ij]; 

vistgt[8]D]=tgt[15]0]; 

n=8; 

} 

goto END; 

} 


END: 

return; 


/* This function round up or down to the nearest integer for ix */ 
nintxQ 

{ 


ix=floor(x); 

zx=fabs(x-ix); 

if (tx >= .5) 


{ 

ix=ceil(x); 
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} 


else 


{ 

ix=floor(x); 

} 


return; 

} 

nintyO ***************♦****♦*****♦*♦*♦/ 
/* This function round up or down to the nearest integer for iy */ 
nintyO 

{ 


iy=floor(y); 

zy=fabs(y-iy); 

if (zy >= .5) 

{ 

iy=ceil(y); 

} 

else 

{ 

iy=floor(y); 

} 


return; 

} 


/♦♦♦♦******+*****^*+**^*^^^*^^^ compareO ***********************+*+***/ 
/* This function compares LOS data to terrain data to see if LOS is obstructed */ 
compareO 

{ 
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/* Compares LOS height to ground height */ 


if (z < zdirt) 

{ 

nolos=l; 

} 

else if (z < ztree) 

{ 

/* The following determine attenuation due to vegetation. If feature is 200 m away 
then appears as solid object, distance arbitrarily selected. Checks UCI if object has 
height but no UCI assume to be trunk of object/man made structure, LOS blocked */ 
if (uci[ix*50+iy] = 0) 

{ 

nolos=2; 

} 

else if (z > uci[ix*50+iy]) 

{ 

/* Checks nature bit, structures block LOS. Manmade objects have a nature bit of 0 */ 
if (nat[ix*50+iy] = 0) 

{ 

nolos=3; 

} 

/* If program passes test above then obstruction is vegetation and any other parts of 
tree will be assumed as foliage. Current assumption is foliage of 1 meter thickness 
has an attenuation of 30%. This value is modified as a function of distance until the 
modified value reaches an attenuation of 100% at terminal distance, 200 meters. At 
200 meters all objects appear solid. It is assumed the modification factor is linear */ 
if (dist > 200) 
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{ 

nolos=4; 

} 

else 

{ 

attenf^denfol*(l+2.33*dist/200); 

} 

} 

/* Allows for sensor hiding behind or in foliage to see through w/out attenuation */ 
if (dist <= 1) 

{ 

attenf=0; 

} 

/* Sums attenuations */ 

atten=atten+attenf; 

/* If total attenuation exceeds 95%, LOS is blocked */ 
if (atten > .95) 

{ 

nolos=5; 

} 

} 


return; 

} 


/♦t***************,,***,,*,,^,,^,,,, datatgtO ♦♦*****************+f********v 
/* This function displays to screen: range, % of target faces visible, and total area of 
target faces visible */ 
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datatgtO 

{ 


prcnt=floor((r / n)*100); 

printf("\n%d\t%d\t%3.2f\t%d\t%3.2f\n",ext,cyt,range,prcnt,totarea); 
return; 

} 


/* This function creates trees & places them on the terrain from info in "tree.dat" */ 
static void tree() 


{ 


/* Declare variables */ 
int row; 
float rad,x,z; 


/* Opens file "tree.dat" and reads dimensional data */ 
j^l=fopen("tree.dat","r"); 


for (row=0; row<7; row-H-) 

{ 


fscanf(fpl," %f %f %f\n",«&mdata[row][0],&mdata[row][l],&mdata[row][2]); 


/* Defines variables rad, x, z */ 

rad=mdata[ro w] [0] ;x=mdata[row] [ 1 ] ;z=mdata[ro w] [2]; 


I* Defines cube as a new sphere and cyl as a new cylinder, attach’s them together */ 
factorspC]=factors[Z]=.75;factors[Y]=1.2; 
sphere = WTobject_newsphere(rad,5,5,1,1,1); 
>^object_stretch(sphere,factors,p,WTFRAME_WORLD); 
cyl = WTobject_newcylinder(rad/1.25,rad/5,4,l,l,l); 
dp4rX]=0;dp4[Y]=-(.95*rad);dp4[Z]=0; 
WTobject_translate(sphere,dp4,WTFRAME_WORLD); 

WT obj ect_attach(sphere,cyl); 

WT obj ect_add(sphere); 

dp5 CX]=x;dp5 [ Y]=-rad/4;dp5 [Z]=z; 

UT obj ect_translate(sphere,dp5, WTFRAME_W ORLD); 
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} 


fclose(fpl); 

return; 
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APPENDIX!. FLOWCHART PROG3.C 
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APPENDIX K. PROGRAM PROG3.C 


/* PROGRAM PROG3.C */ 




/* This program calculates Line Of Sight (LOS) data and visualizes a target moving*/ 
/* through a 35x50 grid using a database of Pegasus numbers and is designed to */ 

/* incorporate attenuation by vegetation. The main section of this program calls */ 

/* function terrainQ which is used to start WorldToolKit and create a universe */ 

/* where there is a flat terrain with trees and a building located on it. The trees and*/ 
/* building are represented as the LOS algorithm would see them. The simulation */ 

/* has the target moving along a path behind the trees and building. Fimction * / 

/* terrainQ calls function losQ which is used to calculate target data. */ 
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/* Standard C and WorldToolKit header files */ 
#include <stdio.h> 

#include <math.h> 

#include"wt.h" 

#include"wt.p" 


/* Defines a pointer spaceball to structure type WTsensor */ 
static WTsensor *spaceball=NULL; 


/* Defines windows, viewpoints, nodes, and paths */ 

static WTwindow *winl, *win2, *win3; 

static WTviewpoint *view, *objviewl, *objview2, *objview3; 

/* Defines objects */ 

WTobject *bldg, *copy, *cyl, *original, *sensor, *sphere, *cube, *terrobj; 
WTobject *nodeobj, *tree3ml, *tree3m2, *tree3m3, *tree3m4, *tree3m5; 
WTobject *tree8mlc, *tree8mlol, *tree8mlo2, *tree8mlo3, *tree8mlo4; 
WTobject *tree8m2c, *tree8m2ol, *tree8m2o2, *tree8m2o3, *tree8m2o4; 
WTobject *tree, *target; 


/* Defines path */ 
static WTpath *tnkpth; 

/* Defines pointers to WTp3, WTq,and WTpq structures */ 

WTp3 at,dpl,dp2,dp3,dp4,dp5,dp6,dp7,dp8,dir,factors,p,pl,p2,pppl,ppp2,pp,pt; 
WTp3 dp9,dpl0,dpll,dpl2,dpl3,dpl4,dpl5,dpl6,dpl7,dpl8,dpl9,dp20; 

WTp3 atl, dirl; 

WTq ppl,pp2; 

WTpq model view; 
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/* Defines light object to be a pointer to type WTlight */ 
WTIight *mylight; 


/* Initialize arrays and declares variables */ 

int &ns,c,cxt,cyt,ho,ht,i,ix,iy,istart,istop,j,n,nmbr,nolos,prcnt; 

int win,wdow,xs,xt,xmax,xmin,xstart,ys,yt,ymax,ymin,ystart,zs,zt,zdirt,ztree; 

int binelev[1750],binnat[1750],binuci[1750],binvghindex[1750],binvid[1750]- 

int elev[1750],nat[1750],realvgh[10],tgt[17][5],tile[1750]; 

int uci[1750],vgh[1750],vid[1750],vghindex[1750],vistgt[9][9]; 

float aproj,atten,attenf,dx,dy,dz,denfol,dist,r,rad,rdx,rdy,row,rdns,range; 

float totarea,visaproj,x,y,y_rotate,z,zx,zy; 

float mdata[7][3],tc; 

/* Standard C file pointers */ 

FILE *fp; 

FILE *fpl; 

mainQ 

{ 


/* Reads database information into array fi-om data file "btlfld_terr.dat" */ 
fp=fopen("btlfld_terr.dat","r"); 
for (i=0; i<=1749; i-H-) 


{ 

fscanf(^," %d", &tile[i]); 

} 

fclose(fp); 

/* Assigns 1 meter of foliage an attenuation of 30% of the LOS */ 
denfol=0.3; 

/* The vegetation height from pegasus has values of 0-15, each of these values 

represents a particular height or range of heights. The following is used to correlate 
the vgh value to a meaningful height */ 
realvgh[0]=0; 
realvgh[l]=0; 
realvgh[2]=l; 
realvgh[3]=2; 
realvgh[4]=3; 
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realvgh[5]=4; 

realvgh[6]=5; 

realvgh[7]=8; 

realvgh[8]=10; 

realvgh[9]=15; 

realvgh[10]=20; 

realvgh[l 1]=25; 

realvgh[12]=30; 

realvgh[13]=35; 

realvgh[14]=40; 

realvgh[15]=47; 

/* Once the database for the grid desired has been read into an array, the components 
of information are extracted from the 32 bit number using the AND and SHIFT 
functions. The groups of information of use in the program are placed in their own 
arrays for rapid recdl during calculations as follows: 


elevation of highest point in grid - ELEV 

under cover index - UCI 

converted vegetation height - VGH 

vegetation ID - VID 

nature bit . NAT */ 

for (i=0; i<=1749; i-H-) 


{ 

binuci[i]=tile[i] & 786432; 
binvgiiindex[i]=tile[i] & 15360; 
binvid[i]=tile[i] & 768; 
binnat[i]=tile[i] & 128; 
binelev[i]=tile[i] & 4292870144; 

uci[i] = binucip] » 18; 
vghindex[i] = binvghindex[i] » 10; 
vgh[i]=realvgh[vghindex[i]]; 
vid[i] = binvid[i] » 8; 
nat[i] = binnat[i] » 7; 
elev[i] = binelev[i] » 21; 

} 

/* This program is currently written to run in a stand alone mode. Sensor information 
has a default value, but can be changed by answering prompts from the keyboard 
Prompts to accept default values or input sensor location and height */ 
printf("\nThe Default Sensor Coordinates are xs = 0, zs = 0"); 
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printf("\nand hs = IVn"); 

printf("\nDo you wish to Change these values? l=Yes, 2=No\n"); 
scanf(" %d",&ans); 

if (ans = 1) 

{ 

BEGIN: 

printf("\nEnter Sensor X Coordinate (X,Y)\n"); 
scanf("%d,%d",&xs,&ys); 
printf("\nEnter Sensor Height\n"); 
scanf("%d",&ho); 

printf("\nAre You Sure? l=Yes 2=No \n"); 
scanf(" %d", &ans); 


if (ans = 2) 

{ 

goto BEGIN; 

} 

} 

else 

{ 

xs=0; 

ys=0; 

ho=l; 

} 

printf("\nPress Spaceball Button 1 to add a window\n"); 
printf("\nPress Spaceball Button 2 to delete window added\n"); 
printf("\nPress Spaceball Button 3 to start target motion\n"); 
printf("\nPress Spaceball Button 4 to replay simulation\n"); 
printf("\nPress Spaceball Button 8 to end simulation\n"); 

/* Calls function terrainQ */ 
terrain(); 

return; 
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} 
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/* This function is WorldToolKit */ 
terrainQ 

{ 

void my actionsQ; 

/* Creates new universe */ 

WTuniverse_new(WTDISPLAY_DEFAlJLT,WTWINDOW_DEFAULT); 

/* Creates the object terrobj */ 

terrobj=WTterrain_flat(0.0,35,50,0,0,1.0,1.0,0x0f0,0x0e0,1.0); 

/* Defines pose of lights, and create light object*/ 
at[0]=0.0;at[l]=-25.0;at[2]=25.0; 
dir[0]=5;dir[l]=.5;dir[2]=5; 
mylight=WTlight_new(at,dir, 1.0); 
atl [0]=35.0;atl [l]=-25.0;atl [2]=25.0; 
dirl [0]=-.5;dirl [l]=.5;dirl [2]=-.5; 
mylight=WTlight_new(atl ,dir 1,1.0); 

/* Creates the object spaceball or mouse */ 
spaceball=WT spaceball_new(COM 1); 

/* Creates small building, sensor, and target, and places them on the terrain */ 
bldg=WTobjectnewblock(3,-8,3,1,1); 
dpi [X]=29;dpl [Y]=-4;dpl [Z]=29; 
WTobject_translate(bldg,dpl,WTFRAME_WORLD); 
WTobject_changecolor(bldg,0xfff,0x777); 

sensor=WTobject_newblock(.5,.5,.5,1,1); 
dp2[X]=0.0;dp2[Y]=-.250;dp2[Z]=0.0; 

WTobject_setposition(sensor,dp2); 

WTobject_changecolor(sensor,0xffF,0xf0f); 

/* Target is loaded from extemed Autodesk dxf file */ 

cube=WTobject_new("cubetgt.dxf',&modelview, 1.0,FALSE,FALSE); 
dp3pC]=15.0;dp3[Y]=5.0;dp3[Z]=25.0; 

WTobject_setposition(cube,dp3); 

WTobject_changecolor(cube,0x000,0xfff); 
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/* Target path is loaded from external file */ 

nodeobj=WTobject_newblock(. 111,1,1); 
tnkpth=WTpath_load("cube.pth",nodeobj); 

/* Creates trees */ 

tc = 0x777; 

tree3m 1 =WTobject_newblock( 1,3,1,1»1); 
dp4[X]=l 7.0;dp4[Y]=-l .5;dp4[Z]=27.0; 
WTobject_setposition(tree3m 1 ,dp4); 
WTobject_changecolor(tree3m 1,0xfff,tc); 
tree3m2=WTobject_newblock( 1,3,1,1,1); 
dp5[X]=l 7.0;dp5[Y]=-l .5;dp5[Z]=33.0; 
WT object_setposition(tree3 m2,dp5); 
WTobject_changecolor(tree3m2,0xfff,tc); 
tree3m3=WTobject_newblock( 1,3,1,1,1); 
dp6[X]=19.0;dp6[Y]=-l .5;dp6[Z]=31.0; 
WTobject_setposition(tree3m3,dp6); 

WT obj ect_changecolor(tree3 m3,0xfff,tc); 
tree3m4=WTobject_newblock( 1,3,1,1,1); 
dp7pC]=18.0;dp7[Y]=-1.5;dp7[Z]=34.0; 
WTobject_setposition(tree3m4,dp7); 
WTobject_changecolor(tree3m4,0xfff,tc); 
tree3m5=WTobject_newblock( 1,3,1,1,1); 
dp8[X]=22.0;dp8[Y]=-1.5;dp8[Z]-33.0; 
WTobject_setposition(tree3m5,dp8); 
WTobject_changecolor(tree3m5,0xfff,tc); 
tree8ml c=WTobject_newblock( 1,8,1,1,1); 
dp9pC]=12.0;dp9[Y]=-4.0;dp9[Z]=36.0; 
WTobject_setposition(tree8m 1 c,dp9); 
WTobject_changecolor(tree8m 1 c,0xfff,tc); 
tree8m 1 o 1 = WT obj ect_newblock( 1,4,1,1,1); 
dpl0[X]=12.0;dpl0[Y]=-3.0;dpl0[Z]-35.0; 
WTobject_setposition(tree8m 1 o 1 ,dpl 0); 
WTobject_changecolor(tree8ml o 1,0xfff,tc); 
tree8m 1 o2=WTobject_newblock( 1,4,1,1,1); 
dpi l[X]=13.0;dpl l[Y]-3.0;dpl l[Zh36.0; 
WTobject_setposition(tree8mlo2,dpll); 
WTobject_changecolor(tree8mlo2,0xfff,tc); 
tree8ml o3=WTobject_newblock( 1,4,1,1,1); 
dpl2[X]=12.0;dpl2[Y]=-3.0;dpl2[Z]=37.0; 
WTobject_setposition(tree8m 1 o3,dpl 2); 
WTobject_changecolor(tree8m 1 o3,0xfff,tc); 
tree8m 1 o4=WTobJect_newblock( 1,4,1,1,1); 
dpl3pC]=11.0;dpl3[Y]=-3.0;dpl3[Z]=36.0; 
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WTobject_setposition(tree8m 1 o4,dp 13); 
WTobject_changecolor(tree8mlo4,0xfff,tc); 
tree8m2c=WTobject_newbIock( 1,8,1,1,1); 
dpl4pC]=26.0;dpl4[Y]=-4.0;dpl4[Z]=35.0; 
WTobject_setposition(tree8m2c,dp 14); 
WTobject_changecolor(tree8m2c,0xfff,tc); 
tree8m2o 1 =WTobject_newblock( 1,4,1,1,1); 
dpl5[X]=26.0;dpl5[Y]=-3.0;dpl5[Z]=34.0; 
WTobject_setposition(tree8m2o 1 ,dp 15); 
WTobject_changecoIor(tree8in2o 1 ,Oxfiff,tc); 
tree8m2o2=WTobject_newblock( 1,4,1,1,1); 
dpl6[X]=27.0;dpl6[Y]=-3.0;dpl6[Z]=35.0; 
WTobject_setposition(tree8m2o2,dp 16); 
WTobject_changecolor(tree8m2o2,0xfff,tc); 
tree8m2o3=WT object_newblock( 1,4,1,1,1); 
dpi 7[X]=26.0;dpl 7[Y]=-3.0;dpl 7[Z]=36.0; 
\^object_setposition(tree8m2o3,dpl7); 
WTobject_changecolor(tree8in2o3,0xfff,tc); 
tree8m2o4=WTobject_newblock(l ,4,1,1,1); 
dpi 8[X]=25.0;dpl 8[Y]=-3.0;dpl 8[Z]=35.0; 
WTobject_setposition(tree8m2o4,dp 18); 
WTobject_changecolor(tree8m2o4,0xfff,tc); 

/* Prints to screen title headings */ 

printf("\nxt\tyt\trange\tprcnt\ttotarea"); 
printf("\n__\t__\t_ \t _ \t _^\n"); 

/* Sets universe action function to my_actionsO */ 
WTuniverse_setactions(my_actions); 

/* Prepares for simulation to start */ 

WTxmiverse_ready(); 

/* Scales spaceball or mouse sensitivity to the size of the universe */ 

WTsensor_setsensitivity(spaceball, 5.0 *WTuniverse_getradius()); 

/* Connects the viewpoint to the spaceball or mouse */ 
WTviewpoint_addsensor(view,spaceball); 

/* Puts some lights on in the universe */ 

WTlight_setambient(0.4); 
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/* Enters main simulation loop and starts simulation */ 

WT uni verse_go(); 

/* Deletes universe, simulation loop must be exited to reach this statement */ 
WTuniversedeleteO; 

return; 


/* This function determines what actions will occur in the universe */ 
void my_actions() 

{ 


/* Sets default universe viewpoint */ 

view=WT uni verse_ 5 etvie wpointO; 
pi [X]=xs;pl [Y]=-ho;pl [Z]=ys; 
ppl CX]-0.0;ppl [Y]=0.0;ppl [Z]=0.0;ppl [W]-l .0; 
pppl [X]=l .0;pppl [Y]=0.0;pppl [Z]=l .3; 

WT vie wpoint_setposition(vie w,p 1); 
WTviewpoint_setorientation(view,ppl); 

WT viewpoint_setdirection(vie w,ppp 1); 

/* Pressing spaceball button ONE adds an additional window */ 

if(WTsensor _getmiscdata(spaceball)&WTSPACEBALL_BUTTON 1 ) 

{ 

win2=WTwindow_new(505,500,250,400,WTWINDOW_DEFAULT); 
obj vie w2= WT viewpointne w(); 

p2[X]=17.5;p2[Y]=-25.0;p2[Z]=25.0; 
pp2pC]=0.0;pp2[Y]=0.0;pp2[Z]=0.0;pp2[W]=1.0; 
ppp2pC]=0.0;ppp2[Y]=l .0;ppp2[Z]=0.0; 
WTviewpoint_setposition(objview2,p2); 
WTviewpoint_setorientation(objview2,pp2); 
WTviewpoint_setdirection(objview2,ppp2); 

WT window_setviewpoint( win2,obj vie w2); 

} 

/* Pressing spaceball button TWO deletes the first window added */ 

if(WTsensor _getmiscdata(spaceball)&WTSPACEBALL_BUTTON2) 
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{ 

WTwindow_delete(win2); 

} 

/* Pressing spaceball button THREE starts the target motion */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON3) 

{ 

WTpath_setobject(tnkpth,cube); 

WTpath_play(tnkpth); 

WTpath_record(t^pth); 

} 

/* Pressing spaceball button FOUR restarts the target motion */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON4) 

{ 

WTpath_stop(tnkpth); 

WTpath_rewind(tnkpth); 

WTpath_play(tnkpth); 

} 

/* Based on target position, function tgtposnQ called */ 
WTobject_getposition(cube,pp); 

if(pp[X] = 2) 

{ 

tgtposnO; 

} 

if(ppPq = 7) 

{ 

tgtposnO; 
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} 


if (pp[X] = 12) 

{ 

tgtposnO; 

} 

if(pp[X]= 17) 

{ 

tgtposnO; 

} 

if (ppPC] = 22) 

{ 

tgtposnO; 

} 

if (ppCX] = 26) 

{ 

tgtposnO; 

} 

if(pp[X] = 30) 

{ 

tgtposnO; 

} 

if ((ppPC] = 33) && (pp[Z] = 37)) 
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{ 


tgtposnO; 

} 

if ((pp[X] = 33) && (pp[Z] == 32)) 

{ 

tgtposnO; 

} 

if ((ppPC] = 33) && (pp[Z] = 27)) 

{ 

tgtposnO; 

} 

if ((pp[X] = 33) && (pp[Z] = 22)) 

{ 

tgtposnO; 

} 

/* Pressing spaceball button EIGHT terminates simulation */ 

if(WTsensor_getmiscdata(spaceball)&WTSPACEBALL_BUTTON8) 

{ 

WTuniversestopO; 

} 


return; 

} 
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/ This function calls los() and datatgtQ, receives value of xt and zt from 
WTobject_getposition, and displays target data to screen */ 
tgtposnO 


{ 


xt=pppC];yt=pp[Z]; 

/* Calls function losQ to determine LOS to target faces, and other calculations */ 
losQ; 

/* Calls function datatgtQ to display target data */ 
datatgtQ; 

/* Zeros out total area and percent data */ 
totarea=0; 
prcnt=0.0; 

return; 


+ *********♦**♦****♦****♦****♦****/ 
/* This function calculates LOS data */ 

losQ 

{ 


/* Begins loop inputting targets moving locations */ 
cxt=xt; 
cyt=yt; 

range=sqrt((float)pow((xt-xs),2)+(float)pow((yt-ys),2)); 

/* Calls the function aspectQ to determine how much of the target is presented for 
possible LOS. Vistgt[ ][ ] is the array returned holding the grid location and 
infomation on the faces of the target which may be seen, n = the number of 
possible detections and is used for looping the algorithm */ 
aspectQ; 

/* Loops to check possible LOS for all surfaces presented by target */ 
r=0; 

for (j=l; j<=n; j++) 


134 


{ 


/* Zeros atten for each run and gets target grid height data for stepping LOS */ 
atten=0; 
attenf=0; 
xt=vistgt[j][l]; 
yt=vistgt0][2]; 
ht=vistgt0][3]; 

/* Calculates target and observer heights. First ground height must be found by 
subtracting vegetation height from absolute height. Then sensor and target heights 
above ground are added to obtain absolute elevations of sensor and target */ 
zs=elev[xs*50+ys]-vgh[xs*50+ys]; 
zt=elev[xt*50+yt]-vgh[xt*50+yt]; 
zs=2S+ho; 
zt=zt+ht; 

/* Determines difference btwn x & y coordinates, and convert from integer to real */ 
rdx=(xt-xs); 
rdy=(yt-ys); 

/* If rdy > rdx, skip to stepping in y direction, else proceed stepping in x direction */ 
if (rdy >= rdx) 

{ 

gotoYSTEP; 

} 

else 

{ 


y=ys; 

dy=(yt-ys)/rdx; 

z=zs; 

dz=(zt-zs)/rdx; 

/* This if-else statement ensures moving from sensor to target. Move only from 
sensor because dist from sensor will affect attenuation level of any obstructions */ 
if (xt > xs) 

{ 
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/* Apply slope to each step to determine grid passing thru and LOS height in that grid 
compare height to ground height, no LOS will exist if ground height > LOS height* 
z = height of LOS ' 

ztree = height of vegetation 

zdirt = height of the ground */ 

istart=xs+l; 

istop=xt; 

ystart=y; 

for (ix=istart; ix<=istop; ix-H-) 

{ 

y=y+dy; 

z=z+dz; 

nintyO; 

ztree=elev[ix*50+iy]; 

zdirt=ztree-vgh[ix*50+iy]; 

I* Calculate dist from sensor to grid where LOS currently in heading toward target ♦/ 

dist=sqrt((float)pow((istart-ix),2)+(float)pow((ystart-iy),2)); 

/* Calls function compareQ */ 
compareO; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

else 

{ 


istart=xs-l; 

istop=xt; 

ystart=y; 
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for (ix=istart; ix<=istop; ix-) 


{ 

y=y+dy; 

z=z+dz; 

nintyO; 

ztree=elev[ix*50+iy]; 
zdirt=ztree-vgh[ix* 50+iy]; 

dist=sqrt((£loat)pow((istart-ix),2)+(float)pow((ystart-iy),2)); 

/* Calls function compareQ */ 
compareO; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

} 

/* This section is used if stepping in y direction and same as stepping in x direction */ 
YSTEP: 


x=xs; 

dx=(xt-xs)/rdy; 

z=zs; 

dz=(zt-zs)/rdy; 
if (yt > ys) 

{ 


istart=ys+l; 

istop=yt; 
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xstart=x; 


for (iy=istart; iy<=istop; iy-H-) 


( 


x=x+dx; 

z=z+dz; 

nintxO; 

ztree=elev[ix* 50+iy]; 
zdirt=ztree-vgh[ix* 50+iy]; 

dist=sqrt((float)pow((xstart-ix), 2 )+(float)pow((istart-iy), 2 )); 

/* Calls function compareQ */ 
compareQ; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

else 

{ 


istart=ys-l; 

istop=yt; 

xstart=x; 

for (iy=istart; iy<=istop; iy-) 

{ 

x=x+dx; 

z=z+dz; 

nintx(); 

ztree=elev[ix*50+iy]; 
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zdirt=ztree-vgh[ix* 50+iy]; 

dist=sqrt((float)pow((xstart-ix),2)+(float)pow((istart-iy),2)); 

/* Calls function compareQ */ 
compareO; 

if (nolos != 0) 

{ 

goto FINISH; 

} 

} 

goto CONTINUE; 

} 

CONTINUE: 

/* At this point LOS has atten = 0 or a number. Apply this attenuation factor to proj 
area of target to reduce area of visibility. Proj area is determined based on surface 
direction of face in question. This value is 1 for a vertical surface and 2 for a 
horizontal surface. This value is stored in vistgt[ ][ ] array which describes target */ 
if (vistgt[j][4] = 0) 

{ 

aproj=rdy/sqrt(pow(rdy,2)+pow(rdx,2)); 

} 

else 

{ 

aproj=rdx/sqrt(pow(rdy,2)+pow(rdx,2)); 

} 

/* Sees if there is any attenuation to be applied, if so apply it */ 
if (atten == 0) 

{ 
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visaproj=aproj; 

} 

else 

{ 

visaproj=( 1 -atten)*aproj; 

} 

/* Sums total visible area presented by target */ 
totarea=totarea+visaproj; 

/* Zeros aproj and visaproj for next LOS */ 
aproj=0; 
visaproj=0; 
r=r+l; 

FINISH: 

nolos=0; 

} 

return; 

} 

Z***********:,*********^**,^^*^^ *****♦*****♦*****♦♦*♦*********/ 

/* This subroutine assigns target grid locations based on central input location. It then 
uses sensor and target locations to determine which faces of target are ideally visible 
to sensor. Faces which are visible have there information stored in array vistgtf ][ ] 
for return to main program. The number of faces ideally visible are also returned. 
Assign target data to array tgt[ ][ ] based on center grid of target 3x3 each exterior 
vertical face of target is represented */ 
aspectO 

{ 


tgt[l][l]=xt-l; 

tgt[l][2]=yt-2; 

tgt[l][4]=0; 

tgt[2][l]=xt-2; 

tgt[2][2]=yt-l; 

tgt[2][4]=l; 
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tgt[3][l]=xt-2; 

tgt[3][2]=yt; 

tgt[3][4]=l; 

tgt[4][l]=xt-2; 

tgt[4][2]=yt+l; 

tgt[4][4]=l; 

tgt[5][l]=xt-l; 

tgt[5][2]=yt+2; 

tgt[5][4]=0; 

tgt[6][l]=xt; 

tgt[6][2]=yt+2; 

tgt[6][4]=0; 

tgt[7][l]=xt+l; 

tgt[7][2]=yt+2; 

tgt[7][4]=0; 

tgt[8][l]=xt+2; 

tgt[8][2]=yt+l; 

tgt[8][4]=l; 

tgt[9][l]=xt+2; 

tgt[9][2]=yt; 

tgt[9][4]=l; 

tgt[10][l]=xt+2; 

tgt[10][2]=yt-l; 

tgt[10][4]=l; 

tgt[ll][lj=xt+l; 

tgt[ll][2]=yt-2; 

tgt[ll][4]=0; 

tgt[12][l]=xt; 

tgt[12][2]=yt-2; 

tgt[12][4]=0; 

tgt[13][l]=xt; 

tgt[13][2]=yt-l; 

tgt[13][4]=0; 

tgt[14][l]=xt-l; 

tgt[14][2]=yt; 

tgt[14][4]=l; 

tgt[15][l]=xt; 

tgt[15][2]=yt+l; 

tgt[15][4]=0; 

tgt[16][l]=xt+l; 

tgt[16][2]=yt; 

tgt[16][4]=l; 


/* Assigns target heights, in tgt[ ][ ] */ 
for G=l; j<=12; j++) 

{ 

tgtU][3]=l; 

} 

for 0=13; j<=16; j++) 

{ 

tgtD][3]=2; 

} 

/* Establishes bounds of the target */ 
xmax=xt+l; 
xmin=xt-l; 
ymax=yt+l; 
ymin=yt-l; 


/* Determines visible sectors of target */ 

if ((xs <= xmax) && (xs >= xmin)) 

{ 

if (ys > ymax) 

{ 

/* Sensor is directly above target grids, upper faces */ 
for 0=1; j<=4; j++) 

{ 

vistgt[l][j]=tgt[5][j]; 

vistgt[2]|j]=tgt[6][j]; 

vistgt[3]|j]=tgt[7]|j]; 

vistgt[4]0]=tgt[15]D]; 

n= 4 ; 
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/* Allows for skewed view of a top block side */ 
if (xs < xt) 

{ 

vistgt[5]|j]=tgt[14][j]; 

n=5; 

} 

if (xs > xt) 

{ 

vistgt[5][j]=tgt[16][j]; 

n=5; 

} 

} 

goto END; 

} 

else 

{ 

/* If the sensor is vertically in line with target grids and it is not above target it must 
be below it, therefore it sees lower faces */ 
for (j=l; j<=4; j-H-) 


{ 

vistgt[l][jHgt[l][j]; 

vistgt[2][j]=tgt[12]D]; 

vistgt[3]D]=tgt[ll]D]; 

vistgt[4][j]=tgt[13][j]; 

n=4; 

/* Allows for skewed view of a top block side */ 
if (xs < xt) 

{ 
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vistgt[5]|j]=tgt[14]0]; 

n=5; 

} 

if (xs > xt) 

{ 

vistgt[5][j]=tgt[16][j]; 

n=5; 

} 

} 

goto END; 

} 

} 

if (xs < xmin) 

{ 

if ((ys >= ymin) && (ys <= ymax)) 

{ 

'* f is horizontally aligned with target grids and to left of target, therefore it sees 
left side faces */ 

for G=l; j<=4; j++) 

{ 

vistgt[l]0]=tgt[2][j]; 

vistgt[2][j]=tgt[3]|j]; 

vistgt[3]0]-tgt[4][j]; 

vistgt[4]0]=tgt[14]D-]; 

n=4; 

/* Allows for skewed view of top block side */ 
if (ys < yt) 
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{ 


vistgt[5]D]=tgt[13]D]; 

n=5; 

} 

if (ys > yt) 

{ 

vistgt[5]0]=tgt[15]D]; 

n=5; 

} 

} 

goto END; 

} 

if (ys < ymin) 

{ 

/* Sensor is to left and below target, all of left side and lower faces seen */ 
for (j=l; j<=4; j-H-) 

{ 

vistgt[l][j]=tgt[l][j]; 

vistgt[2]|j]=tgt[2]0]; 

vistgt[3]D]=tgt[3]D]; 

vistgt[4]0]=tgt[4][j]; 

vistgt[5]D]=tgt[12][j]; 

vistgt[6]0]=tgt[l l][j]; 

vistgt[7][j]=tgt[13]D]; 

vistgt[8]0]=tgt[14]|j]; 

n=8; 


goto END; 


145 



} 

if (ys > ymax) 

{ 


/* Sensor is to left side and above target, all of left side and upper faces seen */ 
for (j=l; j<=4; j-H-) 

{ 

vistgt[l]0]=tgt[2][j]; 

vistgt[2]|j]=tgt[3][j]; 

vistgt[3]0]=tgt[4][j]; 

vistgt[4]|j]=tgt[5]|j]; 

vistgt[5]|j]=tgt[5][j]; 

vistgt[6]Ij]=tgt[7][j]; 

vistgt[7][j]=tgt[14][j]; 

vistgt[8]G]=tgt[15][j]; 

n=8; 

} 

goto END; 

} 

} 

/* Sensor is right of target */ 

if ((ys >= ymin) && (ys <= ymax)) 

{ 

/* Sensor horizontally aligned w/target and right of target, therefore right faces seen ♦/ 
for (j=l; j<=4; j-H-) 

{ 

vistgt[l] 0 ]=tgt[ 8 ] 0 ]; 

vistgt[2]0]=tgt[9]U]; 

vistgt[3]0]=tgt[10]0]; 

vistgt[4][j]=tgt[16]G]; 

n=4; 
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/* Allows a skewed view of a top side */ 
if (ys < yt) 

{ 

vistgt[5][j]=tgt[13][j]; 

n=5; 

} 

if (ys > yt) 

{ 

vistgt[5]D]=tgt[15]D]; 

n=5; 

} 

} 

goto END; 

} 

if (ys < ymin) 

{ 

/* Sensor is right of and below target, all right and lower faces seen */ 
for 0=1; j<=4; j-H-) 


{ 

vistgt[l]0]=tgt[8]D]; 

vistgt[2][j]=tgt[9][j]; 

vistgt[3]D]=tgt[10]D]; 

vistgt[4]0]=tgt[l]D]; 

vistgt[5][j]=tgt[12][j]; 

vistgt[6][j]=tgt[ll]D]; 

vistgt[7][j]=tgt[13]D]; 

vistgt[8]D-]=tgt[16]D]; 

n=8; 
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} 


goto END; 


) 

if (ys > ymax) 

{ 

/* Sensor is right and above target, all right and upper faces seen */ 
for 0=1; j<=4; j-H-) 

{ 

vistgt[l][j]=tgt[8]|j]; 

vistgt[2]lj]=tgt[9][j]; 

vistgt[3]|j]=tgt[10][j]; 

vistgt[4]Ij]=tgt[5]0]; 

vistgt[5][j]=tgt[6][j]; 

vistgt[6][j]=tgt[7][j]; 

vistgt[7]lj]=tgt[16][j]; 

vistgt[8]0]=tgt[15]|j]; 

n=8; 

} 

goto END; 

} 


END: 

return; 

} 

/* This function round up or down to the nearest integer for ix */ 
nintx() 

{ 


ix=floor(x); 

zx=fabs(x-ix); 
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if (zx >= .5) 

{ 

ix=ceil(x); 

} 

else 

{ 

ix=£loor(x); 

} 


return; 

} 


y%s|ca|ei(e3|e3|es|c:)c:|c3|e:)e:|c:fc:|c%:fe3|c:|c9(e:(c:]c:fc]fc:|c:tci|c3|c:|c«:|()|c njnfyQ 

/* This function round up or down to the nearest integer for iy */ 
nintyO 

{ 


iy=floor(y); 

zy=fabs(y-iy); 

if (zy >= .5) 

{ 

iy=ceil(y); 

} 

else 

{ 

iy=floor(y); 

} 


return; 

} 


149 


compareO **********************>^-^***.*/ 
/* This function compares LOS data to terrain data to see if LOS is obstructed */ 
compareO 

{ 


/* Compares LOS height to ground height */ 
if (z < zdirt) 

{ 

nolos^l; 

} 

else if (z < ztree) 

{ 

/* The following determine attenuation due to vegetation. If feature is 200 m away 
then appears as solid object, distance arbitrarily selected. Checks UCI, if object has 
height but no UCI assume to be trunk of object/manmade structure, LOS blocked */ 
if (uci[ix*50+iy] = 0) 

{ 

nolos=2; 

} 

else if (z > uci[ix*50+iy]) 

{ 

/* Checks nature bit, structures block LOS. Manmade objects have a nature bit of 0 */ 
if (nat[ix*50+iy] — 0) 

{ 

nolos=3; 

} 
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/* If program passes above test then obstruction is vegetation and any other parts of 
tree will be assumed as foliage. Current assumption is foliage of 1 meter thickness 
has an attenuation of 30%. This value is modified as a function of distance until the 
modified value reaches an attenuation of 100% at terminal distance, 200 meters. At 
200 meters all objects appear solid. It is assumed the modification factor is linear */ 
if (dist > 200) 

{ 

nolos=4; 

} 

else 

{ 

attenf=denfol*(l +2.33*dist/200); 

} 

} 

/* Allows for sensor hiding behind or in foliage to see through w/out attenuation */ 
if (dist <= 1) 

{ 

attenf=0; 

} 

/* Sums attenuations */ 

atten=atten+attenf; 

/* If total attenuation exceeds 95%, LOS is blocked */ 
if (atten > .95) 

{ 

nolos=5; 

} 

} 
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return; 

} 

datatgtQ *****************=i‘********=)c**>(</ 

/* This function displays to screen: range, % of target faces visible, and total area of 
target faces visible */ 
datatgt() 

{ 

prcnt=floor((r / n)*100); 

printf("\n%d\t%d\t%3.2At%d\t%3.2f\n",cxt,cyt,range,prcnt,totarea); 

return; 

} 
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